IBM i Versão 7 Edição 3. Disponibilidade Descrição geral da Alta Disponibilidade IBM

Transcrição

1 IBM i Versão 7 Edição 3 Disponibilidade Descrição geral da Alta Disponibilidade IBM

2

3 IBM i Versão 7 Edição 3 Disponibilidade Descrição geral da Alta Disponibilidade IBM

4 Aviso Antes de utilizar estas informações e o respectivo produto suportado, leia as informações em Avisos na página 35. Esta edição aplica-se ao IBM i 7.3 (número de produto 5770-SS1) e a todas as edições e modificações subsequentes até 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. Este documento pode conter referências ao Código Interno Licenciado. O Código Interno Licenciado é Código Máquina e está licenciado ao abrigo dos termos do Acordo de Licença da IBM do Código Máquina. Copyright IBM Corporation 2002, 2015.

5 Índice Descrição geral da Alta Disponibilidade 1 Novidades no IBM i Ficheiro PDF de descrição geral da Alta Disponibilidade Vantagens da alta disponibilidade Desactivações planeadas Desactivações não planeadas Recuperação de desastres Redução da duração da cópia de segurança... 5 Balanceamento de carga Critérios de alta disponibilidade Orçamento Requisitos de tempo de actividade Cobertura de desactivação Objectivo de tempo de recuperação (RTO)... 9 Objectivo de ponto de recuperação (RPO)... 9 Requisitos de resiliência Mudança de recurso e comutação automatizada 10 Requisitos de distância Número de sistemas de cópia de segurança Aceder a uma cópia secundária de dados Desempenho do sistema Componentes da alta disponibilidade Resiliência de aplicações Níveis de resiliência de aplicações Resiliência de dados Resiliência do ambiente Simplicidade Descrição geral do IBM PowerHA SystemMirror for i Comparação de tecnologias de resiliência de dados do PowerHA Unidade lógica comutada Replicação geográfica Metro Mirror Global Mirror HyperSwap de Sistema Completo do DS DS8000 HyperSwap com conjuntos de memória auxiliar independentes (IASPs, independent auxiliary storage pools) Utilizar cenários de casos FlashCopy Tecnologias de HA combinadas Gestão de alta disponibilidade Interfaces do IBM PowerHA SystemMirror for i Interface gráfico do PowerHA Opção 41 (HA Switchable Resources) Detecção de falha de nó avançada Função de alta disponibilidade no sistema operativo de base Informações relacionadas com a descrição geral da Alta Disponibilidade Avisos Informações da interface de programação Marcas comerciais Termos e condições Copyright IBM Corp. 2002, 2015 iii

6 iv IBM i: Descrição geral da Alta Disponibilidade

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 no IBM i 7.3 Consulte estas novas informações da colecção de tópicos de descrição geral da Alta Disponibilidade Número do programa licenciado Enhanced 7.2 IBM PowerHA SystemMirror for i (5770-HAS) O programa licenciado IBM PowerHA SystemMirror for i não está a ser renovado para 7.3. Isto significa que o número do programa licenciado (5770-HAS) 7.2 é executado no IBM i 7.3 ou IBM i 7.2. O IBM PowerHA for i Enterprise Edition foi melhorado para suportar DS8000 HyperSwap com conjuntos de memória auxiliar independentes (IASPs, independent auxiliary storage pools). Esta nova função faculta um tempo de inactividade de quase zero para desactivações de armazenamento planeadas e não planeadas e poderá ser utilizada com outras tecnologias do PowerHA baseadas em IASPs. Esta função é facultada através de uma nova função de PTF do PowerHA. No IBM Knowledge Center, os termos IASP e conjunto de discos independentes são sinónimos. 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. Pode visualizar ou descarregar estes PDFs que incluem um conjunto de tópicos relacionados: Copyright IBM Corp. 2002,

8 v Tecnologias de Alta Disponibilidade Tecnologia de conjuntos de unidades do IBM i Detecção de falha de nó avançada Domínio administrativo de conjunto de unidades Tecnologias de replicação de dados do PowerHA Gestão de alta disponibilidade Monitorização e Controlo de Recursos (RMC) v Implementar a alta disponibilidade contém os seguintes tópicos: contém os seguintes tópicos: Instalar o programa licenciado IBM PowerHA SystemMirror for i (5770-HAS) Desinstalar o programa licenciado IBM PowerHA SystemMirror for i (5770-HAS) Planear a solução de elevada disponibilidade Implementar o PowerHA Gerir o PowerHA Detecção e correcção de problemas da solução de 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 ( 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 2 IBM i: Descrição geral da Alta Disponibilidade

9 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. Conceitos relacionados: Cobertura de desactivação na página 8 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, Descrição geral da Alta Disponibilidade 3

10 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 aplicaçõ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. Conceitos relacionados: Cobertura de desactivação na página 8 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 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 4 IBM i: Descrição geral da Alta Disponibilidade

11 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. Informações relacionadas: 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. 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 Descrição geral da Alta Disponibilidade 5

12 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. Conceitos relacionados: Cobertura de desactivação na página 8 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: 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 6 IBM i: Descrição geral da Alta Disponibilidade

13 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. Informações relacionadas: Encaminhamento TCP/IP e equilíbrio do volume de trabalho Criar CRGs de par 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) Descrição geral da Alta Disponibilidade 7

14 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 desactivação deve ser calculado com base no pior período de tempo possível. Cobertura de desactivação 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. 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 Conceitos relacionados: 8 IBM i: Descrição geral da Alta Disponibilidade

15 Desactivações planeadas na página 2 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 3 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 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. As opções empresariais são: v Nada requer resiliência v Os dados de aplicações Descrição geral da Alta Disponibilidade 9

16 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 Conceitos relacionados: Resiliência de aplicações na página 13 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 14 A resiliência de dados é a disponibilidade dos dados necessária num ambiente de produção. Existem várias tecnologias, que lidam com os requisitos da resiliência de dados descritas na secção Benefícios da Elevada Disponibilidade. Estas tecnologias podem ser divididas em duas categorias principais no IBM i replicação lógica ou de software e replicação de disco ou de hardware. Resiliência do ambiente na página 17 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. Conceitos relacionados: Comutação Informações relacionadas: 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, 10 IBM i: Descrição geral da Alta Disponibilidade

17 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. Informações relacionadas: Determinar a configuração do sítio 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 v Quase sempre necessários (quase contínuos) Informações relacionadas: Cópia de segurança a partir de uma segunda cópia Descrição geral da Alta Disponibilidade 11

18 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 Metro Mirror 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. Informações relacionadas: Gerir o desempenho do sistema Valores do sistema: Descrição geral do desempenho 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. 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. Conceitos relacionados: Descrição geral do IBM PowerHA SystemMirror for i na página 18 Após determinar os objectivos e requisitos do negócio, é necessário escolher a solução de elevada disponibilidade do IBM i correcta que se ajusta ao negócio. O IBM PowerHA SystemMirror for i é um produto da IBM que faculta uma solução de elevada disponibilidade completa para ambientes de produção do IBM i. Faculta dados, aplicações e resiliência do ambiente, bem como uma interface de 12 IBM i: Descrição geral da Alta Disponibilidade

19 gestão, que permite uma configuração e funcionamento uniformes. 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 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. Conceitos relacionados: Requisitos de resiliência na página 9 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. Informações relacionadas: 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. Descrição geral da Alta Disponibilidade 13

20 Tornar os programas de aplicação resilientes Aplicações de conjuntos de unidades 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. O Objectivo de tempo de recuperação (RTO) para o seu negócio tem um papel fundamental ao nível da resiliência de aplicações necessária. Tal como é referido no tópico de Componentes da alta disponibilidade, existem diferentes níveis de resiliência de aplicações. Estes níveis de resiliência de aplicações vão desde a ausência de recuperação de aplicações, em que um operador do sistema tem de iniciar a aplicação manualmente, até ao serviço contínuo, em que o utilizador poderá nem chegar a aperceber-se que ocorreu uma desactivação. Os requisitos do seu negócio para que a aplicação esteja disponível ao utilizador após uma falha definem os requisitos para o nível de automatização da recuperação da aplicação resiliente na eventualidade de uma falha do sistema. O contexto de criação de conjuntos de unidades do IBM i dá-lhe a capacidade para automatizar a recuperação da aplicação para diferentes tipos de falhas. O nível de automatização possível depende do nível de codificação para automatizar procedimentos manuais e do tipo de aplicação utilizada pelo seu negócio. Para maximizar a resiliência das aplicações, é necessário automatizar todos os passos manuais de comutação/mudança de recurso com programas de saída e a aplicação tem de ser do tipo cliente-servidor, em que a disponibilidade da aplicação é separada da disponibilidade dos respectivos dados. Resiliência de dados A resiliência de dados é a disponibilidade dos dados necessária num ambiente de produção. Existem várias tecnologias, que lidam com os requisitos da resiliência de dados descritas na secção Benefícios da Elevada Disponibilidade. Estas tecnologias podem ser divididas em duas categorias principais no IBM i replicação lógica ou de software e replicação de disco ou de hardware. 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 facultado por um fornecedor de software independente (ISV) de alta disponibilidade. 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 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. 14 IBM i: Descrição geral da Alta Disponibilidade

21 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. 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. As soluções de replicação lógica podem cobrir tipicamente todos os tipos de desactivações, dependendo da implementação. O objectivo de ponto de recuperação (RPO, recovery point objective) pode ser 0 caso a distância entre sistemas permita o registo em diário remoto síncrono e se todos os objectos replicados forem registados em diário. A utilização do registo em diário remoto assíncrono e a posse de objectos que têm de ser replicados a partir do diário de auditoria aumenta o RPO. Outro desafio possível associado a esta abordagem reside na latência 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. Replicação de hardware A replicação de hardware é executada ao nível do sistema operativo ou do disco em vez do nível do objecto. Uma vantagem destas tecnologias sobre a replicação lógica é que a replicação é executada a um nível inferior e, quando executada de forma assíncrona, existe uma garantia de que ambas as cópias dos dados são idênticas. A desvantagem da tecnologia é que os dados apenas são acessíveis a partir de uma cópia e não é possível utilizar a segunda cópia durante a replicação activa. Descrição geral da Alta Disponibilidade 15

22 Dentro da replicação de hardware, existem novamente duas categorias, a replicação de conjuntos de memória auxiliar independentes (IASPs, independent auxiliary storage pools) e a replicação do sistema completo. O IBM PowerHA SystemMirror for i apresenta várias tecnologias de replicação de hardware baseadas em conjuntos de memória auxiliar independentes ou IASPs. Um ASP independente ou IASP é um conjunto de unidades de disco, que pode ser configurado em separado de um sistema central específico e pode ser activado ou desactivado independentemente. UM IASP é utilizado para segregar dados da aplicação do sistema operativo. Assim, é possível replicar os dados da aplicação através da utilização da replicação de hardware enquanto não se replica o sistema operativo. A implementação de IASPs do IBM i suporta objectos de directório (como por exemplo o sistema de ficheiros integrado (IFS, integrated file system)) e objectos de biblioteca (como por exemplo ficheiros de base de dados). Enquanto que a migração dos dados da aplicação para o IASP é um passo em separado na configuração do ambiente, existem várias vantagens para apenas replicar os dados e não o sistema operativo. As comutações planeadas e não planeadas para o sistema de cópia de segurança são mais rápidas do que se o sistema inteiro for replicado. O sistema de cópia de segurança contém uma cópia separada do sistema operativo e poderá ser utilizado para outros trabalhos enquanto também é utilizado como um sistema de cópia de segurança para a produção. Estas tecnologias podem ser utilizadas para actualizações planeadas do sistema operativo uma vez que existem novamente duas cópias do sistema operativo. Caso a migração dos dados da aplicação para um IASP não seja exequível, também é possível utilizar a replicação de hardware ao nível do sistema, tipicamente denominada de replicação do sistema completo. A replicação geográfica, que é uma tecnologia de replicação do IBM i, poderá ser utilizada num ambiente alojado por i para replicar um sistema de produção. As tecnologias de replicação facultadas pelos sistemas de armazenamento da IBM também poderão ser utilizadas para replicar um sistema inteiro. Embora seja mais fácil de configurar inicialmente, a replicação do sistema completo requer mais largura de banda que a replicação baseada em IASPs. A replicação do sistema completo é mais considerada uma tecnologia de recuperação de desastre que de elevada disponibilidade, uma vez que apenas existe um ambiente de produção e é necessário efectuar um IPL à mesma num outro sistema para uma desactivação planeada ou não planeada. Existem ferramentas e acordos de assistência disponíveis a partir do IBM Lab Services, que ajudam a automatizar e personalizar um ambiente de replicação do sistema completo, caso pretendido. Conceitos relacionados: Comparação de tecnologias de resiliência de dados do PowerHA na página 18 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 seguintes tópicos comparam e contrastam as diferentes tecnologias de resiliência de dados dentro do produto PowerHA. Descrição geral do IBM PowerHA SystemMirror for i na página 18 Após determinar os objectivos e requisitos do negócio, é necessário escolher a solução de elevada disponibilidade do IBM i correcta que se ajusta ao negócio. O IBM PowerHA SystemMirror for i é um produto da IBM que faculta uma solução de elevada disponibilidade completa para ambientes de produção do IBM i. Faculta dados, aplicações e resiliência do ambiente, bem como uma interface de gestão, que permite uma configuração e funcionamento uniformes. Requisitos de resiliência na página 9 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. Informações relacionadas: Planear a resiliência de dados 16 IBM i: Descrição geral da Alta Disponibilidade

23 Servidores de armazenamento suportados por PowerHA Domínio administrativo de conjunto de unidades Tecnologias de replicação de dados do PowerHA 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, RAID 10 e replicação do disco asseguram 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 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. É possível manter estes valores do ambiente lógico consistentes ao longo de múltiplos sistemas através de um domínio administrativo de conjuntos de unidades, replicação lógica ou de um processo manual bem definido. Conceitos relacionados: Requisitos de resiliência na página 9 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. Informações relacionadas: Planear resiliência de ambientes Domínio administrativo de conjunto de unidades Descrição geral da Alta Disponibilidade 17

24 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 SystemMirror 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 SystemMirror 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. Descrição geral do IBM PowerHA SystemMirror for i Após determinar os objectivos e requisitos do negócio, é necessário escolher a solução de elevada disponibilidade do IBM i correcta que se ajusta ao negócio. O IBM PowerHA SystemMirror for i é um produto da IBM que faculta uma solução de elevada disponibilidade completa para ambientes de produção do IBM i. Faculta dados, aplicações e resiliência do ambiente, bem como uma interface de gestão, que permite uma configuração e funcionamento uniformes. Esta secção compara as tecnologias disponíveis dentro do produto IBM PowerHA SystemMirror for i. Conceitos relacionados: Resiliência de dados na página 14 A resiliência de dados é a disponibilidade dos dados necessária num ambiente de produção. Existem várias tecnologias, que lidam com os requisitos da resiliência de dados descritas na secção Benefícios da Elevada Disponibilidade. Estas tecnologias podem ser divididas em duas categorias principais no IBM i replicação lógica ou de software e replicação de disco ou de hardware. Componentes da alta disponibilidade na página 12 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. Informações relacionadas: Gerir o PowerHA Tecnologias de replicação de dados do PowerHA Comparação de tecnologias de resiliência de dados do PowerHA 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 18 IBM i: Descrição geral da Alta Disponibilidade

25 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 seguintes tópicos comparam e contrastam as diferentes tecnologias de resiliência de dados dentro do produto PowerHA. Conceitos relacionados: Resiliência de dados na página 14 A resiliência de dados é a disponibilidade dos dados necessária num ambiente de produção. Existem várias tecnologias, que lidam com os requisitos da resiliência de dados descritas na secção Benefícios da Elevada Disponibilidade. Estas tecnologias podem ser divididas em duas categorias principais no IBM i replicação lógica ou de software e replicação de disco ou de hardware. Informações relacionadas: Tecnologias de replicação de dados do PowerHA Planear a resiliência de dados Unidade lógica comutada As unidades lógicas (LUNs, logical units) comutadas permite que os dados que estejam armazenados no conjunto de discos independentes de unidades lógicas criadas num IBM DS8000, Controlador de Volume de SAN ou Storwize sejam comutados entre sistemas, facultando elevada disponibilidade. As LUNs comutáveis são um conjunto de unidades de disco num conjunto de discos independentes controlado por um grupo de recursos de conjunto de unidades do dispositivo e podem ser comutados entre nós dentro de um conjunto de unidades. Quando LUNs comutadas são combinadas com a tecnologia de conjuntos de unidades do IBM i, é possível criar uma solução de elevada disponibilidade simples e rentável para desactivações planeadas e algumas não planeadas. 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 deve estar num IBM System Storage ligado através de uma rede de área de armazenamento. Quando o conjunto de discos independentes é comutado, as unidades lógicas dentro do armazenamento da IBM voltam a ser atribuídas de um sistema para o outro. O benefício de utilizar LUNs comutadas para a resiliência de dados reside na respectiva 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 chave da utilização de LUNs comutadas é a latência de transmissão nula, que poderá afectar qualquer tecnologia baseada em 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. As limitações também são associadas à solução de LUN comutada. Em primeiro lugar, existe apenas uma cópia lógica dos dados que reside no conjunto de discos independentes. Isto poderá ser um único ponto de falha, embora os dados devam ser protegidos através da utilização de RAID 5, RAID 6, RAID 10 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 por exemplo operações de salvaguarda e restauro periódicas, replicação lógica ou de domínio administrativo do conjunto de unidades, para garantir que estes objectos são mantidos. Descrição geral da Alta Disponibilidade 19

26 Outra limitação envolve restrições associadas ao hardware. Um exemplo seriam as desactivações associadas a determinadas actualizações de hardware. O conjunto de discos independentes não pode ser activado online para um sistema com uma edição anterior. Tendo isto em conta, o design e a análise antecipados do ambiente do sistema são essenciais. Características das unidades lógicas comutadas v Todos os dados mantidos no conjunto de dados independente pode ser comutado e disponibilizado no sistema de cópia de segurança. v Não existem problemas com a sincronização de dados. v Conjunto único de dados para minimizar o custo por disco. v Ponto único de falha para dados no conjunto de discos independente. v Solução de sítio único, por isso não possui capacidade de DR v Requer IBM System Storage. v A comutação e a mudança de recurso incluem a activação atempada antes da disponibilização dos dados do conjunto de discos independente. v Pode ser utilizada com outras tecnologias Consulte Servidores de armazenamento suportados do PowerHA para obter mais informações sobre as tecnologias de armazenamento facultadas pela IBM. Informações relacionadas: Unidades lógicas comutadas Configurar unidades lógicas (LUNs, logical units) comutadas Gerir unidades lógicas (LUNs, logical units) comutadas Servidores de armazenamento suportados por PowerHA Replicação geográfica A replicação geográfica é uma função do sistema operativo IBM i. Todos os dados que são colocados na cópia de produção do IASP são replicados para um segundo IASP num segundo sistema, talvez remoto. A replicação é executada dentro do sistema operativo, por isso esta solução poderá ser utilizada com qualquer tipo de armazenamento. Existem versões síncronas e assíncronas da replicação geográfica. A replicação geográfica síncrona garante que as duas cópias dos dados são idênticas, mas possui uma limitação de distância, uma vez que a transacção de E/S não irá concluir no sistema de origem até que a E/S também tenha alcançado o sistema de destino. A replicação geográfica assíncrona não possui limitações de distância, mas se o lado de origem falhar inesperadamente, poderá haver alguns segundos de perda de dados. Os benefícios desta solução são essencialmente os mesmos que a solução de LUN comutada com a vantagem adicional de facultar recuperação de desastres para uma segunda cópia a uma distância aumentada. O principal benefício continua a ser a simplicidade operacional. As operações de comutação são essencialmente as mesmas que as da solução da LUN comutada, excepto que o utilizador comuta para a cópia replicada do IASP, o que faz desta uma solução de HA directa para implementar e operar. Como na solução da LUN comutada, os objectos que não se encontram no IASP têm de ser processados por um outro mecanismo como, por exemplo, domínio administrativo e não é possível colocar o IASP online para um 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 encontra-se dentro do sistema operativo IBM i, uma potencial limitação de uma solução de replicação geográfica são impactos de desempenho em certos ambientes de volume de trabalho. Para a replicação geográfica síncrona, durante a execução de trabalhos por lotes intensivos de entrada/saída (E/S), é possível existir alguma degradação de desempenho no sistema principal. Além disso, tenha em atenção o tempo de sistema da unidade central de processamento (CPU, central processing unit) que é requerido para suportar a replicação geográfica. 20 IBM i: Descrição geral da Alta Disponibilidade

27 Não é possível aceder à cópia de segurança do conjunto de discos independentes enquanto a sincronização de dados se encontra em curso. 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 cópia de segurança e, em seguida, anexar novamente o conjunto de discos independentes 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. A replicação geográfica utiliza rastreio de origem e de destino para minimizar esta exposição. Características da replicação geográfica v Todos os dados mantidos no conjunto de discos independente serão replicados numa segunda cópia dos dados num segundo sistema. v A replicação é uma função do sistema operativo IBM i, por isso é possível utilizar qualquer tipo de armazenamento. v A aplicação poderá ser comutada para o sistema de cópia de segurança e poderá operar na cópia do conjunto de discos independentes. v Duas cópias de dados, eliminando o ponto único de falha. v Durante a utilização da replicação geográfica síncrona, é garantido que ambas as cópias do IASP serão idênticas. A replicação geográfica síncrona ao longo de uma distância poderá ter impacto no desempenho da aplicação devido à latência de comunicação. v É possível dispersar geograficamente a segunda cópia dos dados caso utilize a replicação geográfica assíncrona. No caso de uma desactivação não planeada no sistema de origem, são possíveis alguns segundos de perda de dados. v Transmissão de dados através de 1 a 4 linhas de comunicação TCP/IP para maior produtividade e redundância. v É também recomendado que seja utilizada uma linha separada para o sinal de criação do conjunto de unidades, uma vez que a partilha do sinal com a porta de dados pode causar situações de conflito e esgotar o tempo de espera. v Procedimentos de gravação offline e consultas a cópias de segurança dos dados enquanto o conjunto de dados da cópia de segurança está desanexado. v A resiliência dos dados não é mantida enquanto o conjunto de dados da cópia de segurança está desanexado. A resiliência de dados é retomada após a conclusão da ressincronização parcial ou total. v É possível ser utilizada em conjunto com a tecnologia de comutação da LUN do IBM i. v O tempo sistema de desempenho do sistema está associado à execução de replicação geográfica. v É fortemente recomendado que configure os conjuntos de memória auxiliares separados ou utilize trabalhos de utilizador que acedam a conjuntos de discos independentes para evitar que esses trabalhos criem situações de conflito com outros trabalhos no sistema e para utilizar mais espaço de armazenamento do que o desejado. Mais especificamente, os trabalhos de conjunto de discos independente não devem utilizar o conjunto da máquina ou o conjunto base. Se os trabalhos do conjunto de discos independente utilizarem a mesma memória dos trabalhos que não estão a aceder aos conjuntos de discos independentes, os trabalhos do conjunto de discos independente podem monopolizar o conjunto de memória, bloquear os trabalhos e, em situações extremas, bloquear o sistema. A exposição para este tipo de situação é ainda maior ao utilizar a replicação geográfica. v Os objectos registados em diário no conjunto de discos independente irão garantir a actualização dos dados no sistema de destino. v Monitorização simples do processo de replicação. v O custo está associado a um segundo conjunto de discos. v A replicação efectua-se ao nível da página da memória gerida pelo IBM i. Informações relacionadas: Descrição geral da Alta Disponibilidade 21

28 Replicação geográfica Planear replicação geográfica Configurar replicação geográfica Gerir a replicação geográfica Mensagens de replicação geográfica Cenário: Replicação geográfica Metro Mirror A Metro Mirror consiste numa função do servidor do IBM System Storage. Os dados armazenados em IASPs encontram-se em unidades de disco que se encontram no System Storage Server. Esta solução envolve replicação ao nível do hardware para um segundo servidor de armazenamento que utiliza IBM System Storage Copy Services. Cada servidor de armazenamento está ligado a um IBM i diferente. Um IASP é a unidade básica de armazenamento para a função System Storage Peer-to-Peer Remote Copy (PPRC). PPRC faculta uma replicação do IASP para outro servidor do System Storage. O IBM i faculta um conjunto de funções para combinar o PPRC, IASPs e os serviços de recursos de conjuntos de unidades do IBM i para o processamento de comutação e mudança de recursos coordenado através de um grupo de recursos de conjuntos de unidades (CRG, cluster resource group) do dispositivo. É possível combinar esta solução com outras funções de serviços de cópias baseadas no System Storage, incluindo LUNs comutáveis e FlashCopy para uma redução da janela de salvaguarda. A replicação Metro Mirror é 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. Características da Metro Mirror v Solução do servidor IBM System Storage integrada com a estrutura do PowerHA. v A segunda cópia dos dados pode estar geograficamente dispersa por distâncias curtas a longas. v São necessários dois servidores System Storage ou dois conjuntos de dados no mesmo servidor do System Storage. v O custo está associado a um segundo conjunto de discos. v Os procedimentos para guardar offline e as consultas são possíveis enquanto a replicação está suspensa ou a partir de uma cópia pontual dos dados. v A resiliência dos dados não é mantida enquanto o conjunto de dados da cópia de segurança está desanexado. A resiliência dos dados é retomada após a conclusão da ressincronização. v A transmissão de dados é um processo síncrono. A perda de dados em curso não é possível. v O processo da replicação de dados síncrona poderá afectar o desempenho da aplicação caso a largura de banda de comunicações não tenha o tamanho adequado ou se a distância for muito grande. v A Metro Mirror não implica custos, já que é processada pelo servidor de armazenamento. v O registo em diário dos objectos no conjunto de discos independentes assegura que estas alterações são forçadas rapidamente para o disco em que serão depois replicadas para o sistema de destino. v A replicação dos dados do conjunto de discos independente encontra-se no nível do sector do disco, entre os discos em ambos os servidores de armazenamento. Todos os objectos no conjunto de discos independentes serão sincronizados. v Múltiplas linhas de comunicações de Fibre Channel disponíveis para redundância e maior largura de banda. Informações relacionadas: Metro Mirror Planeamento: Metro Mirror Configurar Metro Mirror Gerir a Metro Mirror 22 IBM i: Descrição geral da Alta Disponibilidade

29 Cenário: Metro Mirror Global Mirror Global Mirror utiliza a mesma tecnologia que Metro Mirror excepto o facto da transmissão de dados ser efectuada de forma assíncrona. A Global Mirror no DS8000 e com Controlador de Volume de SAN e volumes de alteração de sistema Storwize requer um terceiro conjunto de discos para manter a consistê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. Características da Global Mirror v Solução do IBM System Storage Server integrada com a estrutura de conjuntos de unidades do PowerHA. v A segunda cópia dos dados pode estar geograficamente dispersa por vários locais distantes. v São necessários dois servidores System Storage. v São requeridas duas cópias dos dados no Servidor do System Storage de destino para garantir a consistência dos dados através de distâncias. v Os procedimentos para guardar offline e as consultas são possíveis a partir de uma cópia dos dados, mantendo a resiliência dos mesmos. v A transmissão de dados é um processo assíncrono. Durante um procedimento em tempo real, a perda de dados é possível. v A replicação assíncrona de dados é um processo que não afecta o desempenho das aplicações. v A replicação dos dados do conjunto de discos independente encontra-se no nível do sector do disco, entre os discos em ambos os servidores de armazenamento. Todos os objectos no conjunto de discos independentes serão sincronizados. v O custo é associado a um segundo e terceiro conjunto de discos. v Não são necessários despesas gerais de sistema para executar a Global Mirror, uma vez que esta é processada pelo servidor de armazenamento. v O registo em diário dos objectos no conjunto de discos independentes assegura que estas alterações são forçadas rapidamente para o disco em que serão depois replicadas para o sistema de destino. v Múltiplas linhas de comunicações de Fibre Channel disponíveis para redundância e maior largura de banda. Informações relacionadas: Global Mirror Planeamento: Global Mirror Configurar Global Mirror Gerir a Global Mirror Cenário: Global Mirror HyperSwap de Sistema Completo do DS8000 HyperSwap de Sistema completo é uma solução de sistema completo que permite unidades lógicas replicadas entre duas unidades do IBM System Storage DS8000. O IBM i poderá comutar o acesso do DS8000 principal para o DS8000 secundário com uma desactivação mínima durante este tempo, facultando uma solução de elevada disponibilidade de impacto mínimo. HyperSwap de Sistema Completo do DS8000 é uma única solução do sistema do IBM i que utiliza dois IBM System Storage Servers e não requer um conjunto de unidades. O IBM i fornece a capacidade para o sistema comutar entre os servidores DS8000 para desactivações do lado do armazenamento, planeadas e não planeadas, sem perda de acesso aos dados durante a comutação. Descrição geral da Alta Disponibilidade 23

30 HyperSwap de Sistema Completo de DS Desactivação planeada de DS Comutação de HyperSwap para DS8000 de reserva Tempo de inactividade quase zero IBM i A IBM i A DS8000 M DS8000 N DS8000 M DS8000 N SYSBAS HyperSwap SYSBAS SYSBAS HyperSwap SYSBAS rzaig Uma vez que o HyperSwap utiliza a função de Metro Mirror do DS8000, as transferências de dados são efectuadas de forma síncrona. Deve ter em atenção as mesmas limitações de distância e os requisitos de banda larga associados aos tempos de transmissão, tal como em qualquer solução, quando são enviadas comunicações. Características do HyperSwap de Sistema Completo v Solução de sistema única. v Uma partição única do IBM i com acesso a dois Sistemas do IBM System Storage. v Dois Servidores do IBM System Storage que estão a utilizar a função de Metro Mirror de IBM System Storage Copy Services Peer-to-Peer Remote Copy (PPRC). v Todas as unidades de disco ligadas ao sistema IBM i têm de se encontrar numa relação Metro Mirror para que HyperSwap funcione. v A transferência de dados é síncrona. v Tempo de inactividade quase zero para desactivações de armazenamento planeadas v Tempo de inactividade mínimo para desactivações de armazenamento não planeadas (segundos a minutos) v Definição de afinidade para permitir a comutação automática de servidores de armazenamento durante uma comutação de PowerVM Live Partition Mobility (LPM) Informações relacionadas: HyperSwap de Sistema Completo do DS8000 Planear para HyperSwap de Sistema Completo do DS8000 Configurar HyperSwap de Sistema Completo do DS8000 Gerir HyperSwap de Sistema Completo do DS8000 DS8000 HyperSwap com conjuntos de memória auxiliar independentes (IASPs, independent auxiliary storage pools) O PowerHA Enterprise Edition suporta DS8000 HyperSwap a um nível de IASP. HyperSwap funciona independentemente para SYSBAS e IASPs. É possível configurar as relações de HyperSwap apenas para unidades lógicas SYSBAS, apenas unidades lógicas IASP ou ambas. Características de DS8000 HyperSwap com IASPs v Tempo de inactividade quase zero para desactivações de armazenamento planeadas 24 IBM i: Descrição geral da Alta Disponibilidade

31 v Tempo de inactividade mínimo para desactivações de armazenamento não planeadas (segundos a minutos) v Desactivações do servidor planeadas ou não planeadas processadas por tecnologia comutada de LUN para um tempo de inactividade mínimo. v Todas as unidades de disco ligadas ao sistema IBM i têm de se encontrar numa relação Metro Mirror para que HyperSwap funcione. v Definição de afinidade para permitir a comutação automática de servidores de armazenamento durante uma comutação de PowerVM Live Partition Mobility (LPM) v Capacidade de comutação de PowerHA para uma actualização ou desactivação planeadas do servidor ou do software proprietário do IBM i v Capacidade de mudança de recurso do PowerHA para uma desactivação não planeada do servidor ou do software proprietário do IBM i Informações relacionadas: DS8000 HyperSwap com IASPs Planear DS8000 HyperSwap com conjuntos de memória auxiliar independentes (IASPs, independent auxiliary storage pools) Configurar DS8000 HyperSwap com conjuntos de memória auxiliar independentes (IASPs, independent auxiliary storage pools) Gerir DS8000 HyperSwap com conjuntos de memória auxiliar independentes (IASPs, independent auxiliary storage pools) Utilizar cenários de casos: Esta secção destina-se a demonstrar os possíveis cenários que poderão ser utilizados para trazer elevada disponibilidade e recuperação de desastres para o negócio. Por vezes uma imagem vale mil palavras. Espera-se que estas imagens ajudem o utilizador a determinar que solução funcione melhor para o negócio. Ambiente de comutação HyperSwap + LUN: A maioria dos nossos clientes que utilizam HyperSwap num ambiente de IASP combinam HyperSwap com a tecnologia de comutação de unidades lógicas (LUN, logical unit) PowerHA. Através da combinação destas tecnologias, os clientes obtêm v Tempo de inactividade quase zero para uma desactivação do servidor de armazenamento planeada v Tempo de inactividade mínimo para uma desactivação do servidor de armazenamento não planeada (segundos a minutos) v Capacidade de comutação de PowerHA para uma actualização ou desactivação planeadas do servidor ou do software proprietário do IBM i v Capacidade de mudança de recurso do PowerHA para uma desactivação não planeada do servidor ou do software proprietário do IBM i Descrição geral da Alta Disponibilidade 25

32 Funcionamento Normal 1 2 Comutação de HyperSwap de para DS8000 secundário Tempo de inactividade quase zero IBM i A IBM i B IBM i A IBM i B DS8000 M DS8000 N DS8000 M DS8000 N SYSBAS B HyperSwap SYSBAS B SYSBAS B SYSBAS B SYSBAS A SYSBAS A SYSBAS A SYSBAS A rzaig O diagrama acima representa uma combinação de HyperSwap mais ambiente de comutação da LUN. Caso o DS8000 de produção possua uma desactivação planeada, é possível iniciar uma comutação de HyperSwap para o DS8000 de destino com um tempo de inactividade de quase zero. Este tipo de comutação não envolve a comutação de acesso do IASP do IBM i A para IBM i B ou uma desactivação e activação do IASP. Funcionamento Normal 1 2 Mudança de recurso de HyperSwap não planeada para DS8000 secundário Tempo de inactividade mínimo IBM i A IBM i B IBM i A IBM i B DS8000 M DS8000 N DS8000 M DS8000 N SYSBAS A SYSBAS A' SYSBAS A SYSBAS A HyperSwap SYSBAS B' SYSBAS B SYSBAS SYSBAS B rzaig O diagrama acima representa uma combinação de HyperSwap mais ambiente de comutação da LUN. Caso o DS8000 de produção possua uma desactivação não planeada, uma mudança de recurso do HyperSwap será automaticamente iniciada para o DS8000 de destino com um tempo de inactividade mínimo (segundos a minutos). Este tipo de comutação não envolve a comutação de acesso do IASP do IBM i A para IBM i B ou uma desactivação e activação do IASP. 26 IBM i: Descrição geral da Alta Disponibilidade