quinta-feira, 11 de agosto de 2011

Processadores PA-RISC ( Precision Architeture Risc)

Todos os HP 9000 da serie 800 utilizavam a tecnologia “Precision Architecture Risc (PA-Risc)”. O PA-RISC esta construído dentro dos princípios de Reduced instruction Set Computing (RISC) o que implica a implementação de poucos componentes fornecendo uma confiabilidade superior que quando comparado com sistemas CISC (Complex Instruction Set Computer).

Os estudos mostram que equipamentos CISC gastavam 80% do tempo executando instruções simples (soma, subtração, etc) e os restantes 20% em operações complexas, fazendo uso ainda dos microcódigo (microcódigo: ocorre o acesso à instrução e dentro do processador tem um código que acessa o hardware). No Risc isso não acontece porque tudo já é executado em hardware (elimina microcódigo) as instruções complexas ficam por conta do compilador e todas as operações são feitas em registradores.

A base do PA-RISC é um set de instruções contendo 140 instruções de formato fixo cuidadosamente selecionadas.

O paralelismo de instruções, pipelining (técnica que sobre passa o processamento de instruções, de modo que uma instrução pode iniciar sua execução antes que a anterior tenha terminado) é utilizado eficientemente pelo HP PA-RISC em 5 estágios, aliados a compiladores otimizados e ao seu projeto Load/Store, melhoram a execução de instruções em um único ciclo e expandem a performance do sistema.

O PA-RISC utiliza o sistema operacional HP-UX que é o sistema operacional SYSTEM V da AT&T com implementações desenvolvidas pela Hewlett-Packard como: gráficos, suporte a linguagem nativa e algumas construções do Unix BSD.

O Hardware do PA-Risc

Certas operações do sistema, como o boot, podem necessitar da especificação do endereço de hardware. Portanto, é interessante que os administradores de sistemas conheça a configuração de seu hardware com os respectivos endereços.

Cada periférico possui um único endereço de hardware que identifica a path de conexão da CPU para o device propriamente dito. Essa path é composta pelo endereço de todos os elementos que aparecem entre a CPU e o periférico.

SPU – System Processing Unit. São as unidades de processamento do sistema, sendo basicamente a CPU e memoria.

BUS – São circuitos através do qual os dados trafegam entre os módulos do hardware (CPU, Memoria, Chanel Adapter, device adapter). As placas dos periféricos são conectadas no bus. As maquinas de BUS HP-PB (HP-Precision Bus) com exceção da 890, utilizam somente um BUS, já o modelo 890 utiliza 2 estruturas de BUS; PMB (Processor Main Bus) para processador e memória e HP-PB para I/O.

SLOTS – Local físico onde serão conectados as placas. Cada slot tem um número/letra. Nas maquinas HP-PB, todos os slots são conectados no Bus de precisão.

Device Adapter – É a interface que liga o Bus ao periférico, são conhecidos também I/O cards. Os principais devices adapters são:

    • SCSI – Small Computer System Interface. Tecnologia nova que trabalha com conect/desconect para o Bus, permitindo que periféricos de velocidade diferentes sejam conectados a mesma placa (Discos, Fitas, DVDs, etc).
      Pode-se conectar até 7 devices SCSI para cada adaptador (endereçados de 0 a 6): O ultimo device SCSI deve ter um terminador. O comprimento do cabo não deve exceder 6m.
    • HP-IB – HP Interface Bus – Suporta Discos, Fitas, drivers DVD-ROM, impressoras e ploters. Este Device Adapter tem função para aqueles que possuem periféricos HP-IB antigos e querem aproveita-los. Uma desvantagem deste Device Adapter é o fato de não permitir a conexão de periféricos com velocidades diferentes ( Discos e Fitas por exemplo).
      Pode-se conectar até 4 discos HP-IB. O comprimento do cabo não deve exceder 20m, para interface de velocidade padrão e 15m, para alta velocidade.
      Um extensor pode ser utilizado para transmissões a distancia entre SPU e o periférico atingido, até 1.25km (exceto para discos).
    • MUX – Suporta qualquer ligação serial RS-232, plotters, Access Port e alguns podem ligar modems. Podem ser de 8 e de 16 saídas. O comprimento do cabo pode estar entre 5 e 15 m.
    • LAN – Local Área Network. Conecta redes padrão Ethernet e IEEE 802-3.
    • GPIO – General Purpose I/O. Device Adapter utilizado para Conectar periféricos específicos.
    • PSI – Placa programável onde se carrega os protocolos IBM SNA ou X25.

Processadores Itanium

Tambem Conhecido como IA-64 foi desenvolvido pela Intel e HP, para plataformas SMP de 64 bits “puro-sangue”.

A tecnologia Itanium não usa a arquitetura RISC nem CISC, na verdade a Intel criou uma nova arquitetura chamada de EPIC. Aqui se inicia a 8ª Geração de Processadores.

Esse processador é incompatível com Sistemas Operacionais desenvolvidos para os processadores da linha X86-64, pois estes são compatíveis com 32 e 64 bits.

Fontes de Pesquisas: wikipedia.org, clube do hardware, documentos do site da HP e Intel

Historia do Itanium

História

Desenvolvimento: 1989-2000

Em 1989, a HP determinou que as arquiteturas reduced instruction set computer (RISC) estavam se aproximando do limite de processamento de uma instrução por ciclo.

A HP começou a estudar  uma nova arquitetura, mais tarde nomeado Explicitly Parallel instruction Computing (EPIC).

Essa arquitetura permite que o processador execute múltiplas instruções em cada ciclo de clock. Essa arquitetura de very long instruction word (VLIW), em que uma única palavra de instrução contém instruções múltiplas. Com a EPIC, o compilador determina antecipadamente quais instruções podem ser executadas ao mesmo tempo, tão simplesmente o microprocessador executa as instruções e não precisa definir mecanismos para determinar quais as instruções executar em paralelo.

O principal objetivo desta abordagem é primeiramente permitir uma mais profunda inspeção do código, identificando oportunidades adicionais para execução paralela, e, depois, para simplificar o design do processador e reduzir o consumo de energia, eliminando a necessidade de circuitos de programação para o tempo de execução.

A HP determinou que já não era rentável para os sistemas individuais corporativos das empresas, como ela própria, desenvolver microprocessadores proprietários, então a HP buscou uma parceria com a Intel em 1994 para desenvolver a arquitetura IA-64, que derivou da EPIC. Intel estava disposta a empreender um esforço de desenvolvimento muito grande na IA-64, na expectativa de que o microprocessador resultante seria utilizado pela maioria dos fabricantes de sistemas das empresas. A HP e a Intel deram início a um grande esforço de desenvolvimento conjunto com a meta de entregar o primeiro produto, Merced, em 1998. Durante o desenvolvimento, Intel, HP e analistas da indústria previram que IA-64 iria dominar servidores, workstations e desktops high-end, e eventualmente suplantar as arquiteturas RISC e complex instruction set computer (CISC) para todos os aplicativos de uso geral. A Compaq e Silicon Graphics decidiu abandonar desenvolvimento das arquiteturas Alpha e MIPS, respectivamente, com intenção de migrar para IA-64. Vários grupos desenvolveram sistemas operacionais para a arquitetura, incluindo Microsoft Windows, Linux e variantes UNIX, tais como HP-UX, Solaris, Tru64 UNIX, e Monterey/64 (as três últimas foram canceladas antes de chegar ao mercado). Em 1997, tornou-se evidente que a arquitectura IA-64 e o compilador eram muito mais difíceis de implementar do que se pensava inicialmente, e a entrega de Merced começou a escorregar. As dificuldades técnicas incluindo o transistor de altas contagens necessárias para apoiar as largas instruções e os caches de grandes dimensões. Houve também problemas estruturais no âmbito do projecto, como os dois elementos da equipe conjunta utilizarem métodos diferentes e terem diferentes prioridades. Desde que o Merced foi o primeiro processador EPIC, o esforço de desenvolvimento encontrou mais problemas imprevistos do que a equipe estava acostumada. Além disso, o conceito EPIC depende de capacidade do compilador que nunca haviam sido implementadas antes, de forma que mais investigação era necessário. A Intel anunciou o nome oficial do processador Itanium, em 4 de outubro de 1999. Em poucas horas, o nome Itanic havia sido cunhado em um newsgroup da Usenet, uma referência ao Titanic, o "transatlântico inafundável" que afundou em 1912. Itanic desde então tem sido frequentemente utilizado por The Register, Scott McNealy, e outros[o que implica que o investimento multibilionário no Itanium e à enorme expectativa precoce seria seguido por sua morte relativamente rápida.

Itanium (Merced): 2001

Até o momento que o Itanium foi lançado em junho de 2001, seu desempenho não era superior aos concorrentes processadores RISC e CISC. O Itanium competiu no low-end (principalmente 4-CPU e sistemas menores) com servidores baseados em processadores x86, e em high-end com arquitetura IBM, POWER e a Sun Microsystems com arquitetura SPARC. A Intel reposicionou o Itanium para focalizar no negócio high-end e computação HPC, na tentativa de duplicar o sucesso horizontal do x86 no mercado (isto é, única arquitetura, vários fornecedores de sistemas). O sucesso desta versão do processador inicial foi limitada a substituir PA-RISC em sistemas HP, Alpha em sistemas Compaq e MIPS em sistemas SGI, embora a IBM também entregou um supercomputador baseado neste processador. POWER and SPARC manteve-se forte, enquanto a arquitetura 32-bit x86 continuou a crescer para dentro do espaço da empresa. Com as economias de escala, alimentada pela sua enorme base instalada, x86 manteve-se o eminente "horizonte" na arquitetura em computação empresarial. Apenas alguns milhares de sistemas que usam o processador Itanium original “Merced” foram vendidos, devido ao desempenho relativamente fraco, alto custo e disponibilidade de software limitado. Reconhecendo que a falta de software poderia ser um problema sério para o futuro, a Intel fez milhares destes primeiros sistemas disponíveis para os fornecedores de software independentes (ISVs) para estimular o desenvolvimento. HP e Intel trouxe a próxima geração do processador Itanium 2 ao mercado um ano depois.

Itanium 2: 2002-presente

Itanium 2 em 2003

O processador Itanium 2 foi lançado em 2002, e foi comercializado para servidores corporativos e não para toda a gama de computadores high-end. O primeiro Itanium 2, com o codinome de McKinley, foi desenvolvido em conjunto pela HP e Intel. Ele aliviava muitos dos problemas de desempenho do processador Itanium original, que foram causados por um subsistema de memória ineficiente. McKinley continha 221 milhões de transistores, dos quais 25 milhões foram para a lógica, medido 19,5 milímetros de 21,6 mm (421mm 2)e foi fabricadas em 180 nm, volume de processamento CMOS com seis camadas de metalização de alumínio. Em 2003, a AMD lançou o Opteron, que implementou a sua arquitetura de 64-bit (x86-64). Opteron ganhou rápida aceitação no mercado de servidores corporativos porque forneceu uma atualização fácil de x86. A Intel respondeu através da implementação da arquitetura x86-64 em seus microprocessadores Xeon em 2004. A Intel lançou um novo Itanium 2 membro da família, codinome Madison, em 2003. Madison usava um processo de 130 nm e foi a base de todos os novos processadores Itanium até Montecito ser lançado em junho de 2006. Em março de 2005, a Intel anunciou que estava trabalhando em um novo processador Itanium, codinome Tukwila, a ser lançado em 2007. Tukwila teria quatro núcleos de processador e substituirá o BUS do Itanium com uma nova interface comum de sistemas, que também seria usado por um novo processador Xeon. Mais tarde naquele ano, a Intel revisa a data de entrega do Tukwila para final de 2008. Em novembro de 2005, os principais fabricantes de servidores Itanium se juntaram com a Intel e um número de fornecedores de software para formar o Itanium Solutions Alliance para promover a arquitetura e acelerar a portabilidade de software. A Aliança anunciou que seus membros iriam investir US $ 10 bilhões em soluções Itanium no final da década. Em 2006, a Intel entregou o Montecito, um processador dual-core, que praticamente dobrou o desempenho e diminuiu o consumo de energia por cerca de 20 por cento. A Intel lançou a versão Itanium atual, codinome Montvale, em novembro de 2007. Em maio de 2009, o cronograma para Tukwila, e seu acompanhamento foi novamente revisto, com liberação para OEMs prevista para o primeiro trimestre de 2010. Em comparação com a família de processadores Xeon Server, Itanium não é um produto de alto volume para Intel. A Intel não divulgou o número de produção, mas um analista da indústria estima que a taxa de produção foi de 200.000 processadores por ano em 2007. Segundo o Gartner, o número total de servidores Itanium vendidos por todos os fornecedores em 2007 foi de cerca de 55.000. Isso se compara com os 417.000 servidores RISC (espalhados por todos os vendedores RISC) e 8,4 milhões de servidores x86. De 2001 a 2007 a IDC reporta que um total de 184.000 sistemas baseados em Itanium foram vendidos. Para o mercado de sistemas, o combinado POWER / SPARC / Itanium, em um relatório da IDC informa que o POWER captou 42% e SPARC captou 32%, enquanto as receitas baseadas no sistema Itanium chegaram a 26% no segundo trimestre de 2008. De acordo com um analista da IDC, em HP 2007 representou, talvez, 80% das receitas sistemas Itanium. Segundo o Gartner, a HP em 2008 representaram 95% das vendas Itanium.

A Intel tem amplamente documentado o conjunto de instruções de processadores e microarquitetura, e da imprensa técnica forneceu revisões. A arquitetura foi renomeado várias vezes durante sua história. HP inicialmente chamou-PA-WideWord. Intel mais tarde chamou IA-64, depois de processadores Itanium Architecture (IPA), antes de se estabelecer em Intel Itanium Architecture, mas ainda é amplamente referido como IA-64. É uma arquitetura de 64 bits, totalmente paralela rica em registros. A base da palavra de dados é de 64 bits, byte endereçável. O espaço de endereçamento lógico é 2 64 bytes. A arquitetura implementa pressuposição, especulação, e previsão de desvio. Ele usa um mecanismo de hardware para renomeação de registro, em vez de simples registo de janelas para a passagem de parâmetro. O mesmo mecanismo também é utilizado para permitir a execução paralela de loops. Especulação, previsão, pressuposição, e renomeação estão sob o controle do compilador: cada instrução inclui bits extras para isso. Esta abordagem é a característica distintiva da arquitetura. A arquitetura implementa 128 registros inteiros, 128 registros de ponto flutuante, 64 pressuposição de um bits, e oito registros derivados. Os registros de ponto flutuante de 82 bits preserva a precisão dos resultados intermediários.

Execução da instrução

Cada instrução 128-bit contém três instruções, e a busca do mecanismo pode ler as duas instruções por clock do cache L1 no pipeline. Quando o compilador pode tirar o máximo proveito deste, o processador pode executar seis instruções por ciclo de clock. O processador tem trinta unidades de execução funcional em onze grupos. Cada unidade pode executar um subconjunto específico do conjunto de instruções, e cada unidade é executado a uma taxa de uma instrução por ciclo de execução, a menos barreiras à espera de dados. Embora nem todas as unidades de participação em um grupo executam subconjuntos idênticos do conjunto de instruções, instruções comuns podem ser executadas em várias unidades.

Os grupos de unidade de execução incluem:

  • Seis ALUs de propósito geral, duas unidades integras, uma unidade de mudança
  • Quatro unidades de dados de cache
  • Seis unidades de multimídia, duas unidades de deslocamento paralelo, um multiplicador paralelo, uma contagem de população
  • Duas unidades com ponto flutuante de 82-bits com acumulação-múltipla, Duas unidades com ponto flutuante SIMD com acumulação-múltipla (duas operações de 32-bit cada)
  • Três unidades derivadas

O compilador pode freqüentemente agrupar instruções em conjunto de seis que podem ser executadas ao mesmo tempo. Desde que a unidades de ponto flutuante implemente uma operação de acumulação-múltipla, uma instrução de um único ponto flutuante pode executar o trabalho de duas instruções quando a aplicação requer uma multiplicação seguido por um acréscimo (Isto é muito comum em processamento científico). Quando isso ocorre, o processador pode executar quatro FLOPS por ciclo. Por exemplo, a 800 MHz Itanium tiveram uma avaliação teórica de 3,2 g FLOPS e os mais rápidos processadores Itanium 2, a 1,67 GHz, foi avaliado em 6,67 GFLOPS.

Arquitetura de Memória

De 2002 a 2006, os processadores Itanium 2 compartilhavam uma hierarquia de cache comum. Eles tinham 16 KiB de cache L1 de instruções e 16 KiB de Nível 1 cache de dados. A cache L2 foi unificada (tanto de instruções e dados) e é de 256 KiB. A cache de nível 3 também foi unificada e varia em tamanho de 1,5 MiB a 24 MiB. Os 256 KiB de cache L2 contém lógica suficiente para lidar com operações de semáforo sem perturbar a unidade lógica aritmética principal (ALU). A memória principal é acessada através de um BUS para uma off-chip chip set. O Itanium 2 BUS foi inicialmente chamado de McKinley BUS, mas agora é normalmente referido como o Itanium BUS. A velocidade do BUS vem aumentando com lançamentos novos processadores. As transferências de BUS 2 × 128 bits por ciclo de clock, então a 200 MHz BUS McKinley transfere 6,4 GiB / s), e os 533 MHz BUS Montecito transfere17,056 GiB / s Alterações de arquitetura Processadores Itanium lançado antes de 2006 tinha suporte de hardware para o IA-32 arquitetura para permitir suporte para aplicativos de servidor legado, mas o desempenho para o código IA-32 era muito pior do que para o código nativo e também pior do que o desempenho dos processadores x86 contemporâneos. Em 2005, a Intel desenvolveu o IA-32 Execution Layer (IA-32 EL), um emulador de software que fornece um melhor desempenho. Com Montecito, da Intel, portanto, eliminado suporte de hardware para IA-32 do código. Em 2006, com o lançamento do Montecito, a Intel fez uma série de melhorias para a arquitetura do processador de base, incluindo:

  • Hardware multithreading: Cada núcleo do processador mantém contexto para duas linhas de execução. Quando uma barreira de contexto aparece durante o acesso a memória, o outro segmento pode executar. Intel chama isso de “coarse multithreading” para distingui-lo da tecnologia hiper-threading, A Intel integra em alguns processadores x86 e x86-64. “Coarse multithreading” está bem adaptado à arquitetura Intel Itanium e resulta em um ganho de desempenho significativo.
  • Suporte de hardware para virtualização: Intel adicionou Intel Virtualization Technology (Intel VT), que fornece ao hardware assistências para funções de virtualização do núcleo. A virtualização permite que um software “hypervisor” para executar várias instâncias do sistema operabcional do processador simultaneamente.
  • Melhorias Cache: Montecito acrescentado um cache L2 dividido, que incluí 1 cache L2 dedicado MiB para obter instruções. O original 256 KiB de cache L2 foi convertido para um cache de dados dedicado. Montecito também incluídos até 12 MiB de cache on-die L3.

Suporte de Hardware

A partir de 2009 Vários fabricantes oferecem sistemas Itanium, incluindo HP, SGI, NEC, Fujitsu, Hitachi, e Groupe Bull. Além disso, a Intel oferece um chassi que podem ser usados por integradores de sistema para construir sistemas Itanium. A HP, o único dos principais fabricantes da indústria de quatro servidores para oferecer sistemas baseados em Itanium, hoje, produz pelo menos 80% de todos os sistemas Itanium. A HP teve 7200 sistemas vendidos no primeiro trimestre de 2006. A maior parte dos sistemas vendidos são servidores corporativos e máquinas para a computação em larga escala técnica, com um preço médio de venda por sistema extra de E.U. $ 200.000. Um sistema típico utiliza oito ou mais processadores Itanium.

Chipsets

A Interface BUS Itanium se comunica com o restante do sistema através de um chipset. Fabricantes de servidores Enterprise diferenciam seus sistemas através da concepção e desenvolvimento de chipsets que a interface do processador de memória, interligações, e os controladores de periféricos. O chipset é o coração do sistema de arquitetura de nível para cada projeto do sistema. Desenvolvimento de um chipset custa dezenas de milhões de dólares e representa um importante compromisso para a utilização do Itanium. A IBM criou um chipset em 2003, e a Intel em 2002, mas nenhum deles desenvolveu chipsets para suportar novas tecnologias como DDR2 ou PCI Express... atualmente, existem chipsets modernos para sistemas de apoio às tecnologias, como são fabricados pela HP, Fujitsu, SGI, NEC e Hitachi. O próximo processador Itanium (Tukwila) foi desenhado para compartilhar um chipset comum com o processador Intel Xeon EX (processador Intel Xeon projetado para quatro processadores e servidores maiores). O objetivo é agilizar o desenvolvimento do sistema e reduzir os custos para OEMs de servidor, muitos dos quais desenvolvem tanto para servidores Itanium quanto para Xeon.

O mais novo processador Intel Itanium série 9300 (Tukwila)

Os servidores baseados em Itanium fornecem desempenho escalável e poderoso para ambientes de UNIX e mainframe, e também excelente disponibilidade para as suas aplicações mais críticas. Esses sistemas são ideais para as cargas de trabalho mais intensas de hoje, como aplicações de banco de dados, inteligência corporativa e planejamento de recursos corporativos (ERP).

O mais novo processador Intel Itanium série 9300 fornece mais do dobro do desempenho da geração anterior, além de até seis vezes mais largura de banda de memória, até nove vezes mais largura de banda de interconexão e até oito vezes mais capacidade de memória. Fornece uma incrível escalabilidade e uma base poderosa, flexível e com maior eficiência energética para virtualização, consolidação e gerenciamento de carga de trabalho do data center.

quarta-feira, 10 de agosto de 2011

Configuração de Clusters

Para configurar seu sistema  como um cluster de alta disponibilidade, você deve tomar as seguintes ações:

  • Conheça os requisitos de Hardware e Sistema Operacional;
  • Conheça os requisitos do Banco de Dados;
  • Conheça os requisitos do Servidor de Banco de dados;
  • Configuração da Conectividade.

 

Cada item desses tópicos serão explicados abaixo.

Você pode configurar seu sistema para usar o protocolo SSL (Secure Sockets Layer), um protocolo de comunicação que garante a privacidade e integridade dos dados transmitidos através da rede, para comunicação HDR. Você pode usar o protocolo SSL para conexão entre o servidor primário e secundário e para conexões com RS (Remote Standalone) e SD (Shared Disk) de servidores secundários em uma configuração de alta disponibilidade. Para obter informações de como usar o protocolo SSL, veja a sessão “Secure Sockets Layer Communication Protocol Encryption” do IBM Informix Security Guide.

 

Requisitos de Hardware e Sistema Operacional

Para o funcionamento do cluster de alta disponibilidade, o hardware deve atender certos requisitos.

O hardware deve atender aos seguintes requisitos:

  • O servidor primário e secundário deve ser capaz de executar a mesma imagem do IBM Informix, mesmo que eles não tenha hardware ou o sistema operacional idêntico.  Por exemplo, você pode usar servidores com diferentes sistemas operacionais Linux de 32 bits, porque esses sistemas operacionais pode executar a imagem do Informix. Nessa situação, você não pode adicionar um server com um Linux 64-bit porque esse sistema operacional requer uma imagem de Informix diferente. Cheque o arquivo “machine notes”: você pode usar qualquer combinação de hardware e sistema operacional listado nesse arquivo.
  • O hardware que roda como primário e secundário deve suportar redes.
  • A quantidade de espaço em disco alocado para os dbspaces no servidor primário e secundário devem ser iguais. O tipo de espaço em disco é irrelevante; você pode usar uma mistura de raw device com file system.
  • Os chunks em cada servidores devem ter os mesmos caminhos. Links simbólicos são permitidos para a plataforma UNIX, mas não para a plataforma Windows.

Requisitos do Banco de Dados

O Banco de dados deve atender os seguintes requisitos:

  • Todos os dados devem ser logged.
    Todos os bancos de dados que vai ser replicado devem estar em modo transacional.

    Este requisito é importante  porque o servidor de banco de dados secundário usa registros de logical-log vindo do servidor primário para atualizar os dados que ele gerencia. Se o banco de dados gerenciado pelo servidor primário não esta em modo transacional, para esse banco de dados não será gerado registros de logs,  sendo assim o servidor de banco de dados secundário não terá meios para atualizar os dados.
  • Os dados devem residir no mesmo dbspace ou sbspaces.
    Se o seu banco de dados primário tem objetos armazenados em blobspaces, modificações nos dados dentro desses blobspaces não é replicado como parte normal do processamento HDR. No entanto, objetos grandes mas simples são replicados.
    Objetos grandes, que são armazenados em sbspaces, são replicados. Os sbspaces devem estar em modo transacional. Tipos definidos por usuários (UDTs) são replicados, a menos que estejam armazenados em arquivos do sistema operacional. Tipos de dados com out-of-row são replicados se os dados estão armazenados em sbspace ou em uma tabela diferente no mesmo servidor de banco de dados.
  • O servidor secundário não pode usar compressão de disco.
    Se você usar o recurso do Informix de compressão de disco, dados que são comprimidos na tabela de origem vão ser comprimidos nas tabelas de destino. Você não pode executar compressão no HDR secundário, RS secundário ou SD secundário, porque o HDR destino deve ter as mesmas configurações de dados e físico como o servidor de origem

Requisitos do Servidor do Banco de Dados

Para um par cluster de servidores de alta disponibilidade funcionar, você deve configurar totalmente cada um dos servidores. Você pode então usar os aspectos relevantes para configurar os pares de servidores.

Estes tópicos descrevem as considerações de configuração a seguir para os pares de cluster:

  • Versão do Banco de dados;
  • Configuração do dbspace e chunk;
  • Tamanhos de paginas não padrão em um ambiente HDR;
  • Espelhamento;
  • Configuração do Physical-log;
  • Dbspace e dispositivo de backup para logical-log;
  • Configuração do Logical-log
  • Parâmetros de configurações do HDR;

Versão do Banco de dados

As versões do Informix no servidor primário e secundário deve ser idêntica.

Configuração do dbspace e chunk

o numero de dbspaces, o numero de chunks, seus tamanhos, seus caminhos e seus offsets devem ser idênticos no servidor de banco de dados primário e secundário. Além disso, a configuração deve conter pelo menos um dbspace temporário se o servidor HDR secundário for usado para criação de relatórios de atividades.

Somente no UNIX:

Você poderá usar links simbólicos para os chunks.

Importante: Se você não utilizar links simbólicos para os chunks, você não poderá alterar os caminhos facilmente

Os seguintes parâmetros no ONCONFIG deve ter o mesmo valor em cada servidor de banco de dados:

  • ROOTNAME
  • ROOTOFFSET
  • ROOTPATH
  • ROOTSIZE

Tamanhos de paginas não padrão em um ambiente HDR

O tamanho de paginas de um dbspace e as especificações de buffer são automaticamente propagadas a partir do servidor primário para o secundário. Embora ambos os servidores devem ter o mesmo buffer pools, o numero de buffer no buffer pool não precisam corresponder.

Espelhamento

Você não deve configurar o parâmetro MIRROR  para o mesmo valor nos dois servidores de banco de dados; você pode habilitar espelhamentos em um servidor de banco de dados e desabilitar o espelhamento no outro. Entretanto, se você especificar um chunk espelho para um chunk root do servidor primário, você deve também especificar um chunk espelho para o chunk root do servidor secundário. Portanto, os seguintes parâmetros do ONCONFIG devem ser configurados com o mesmo valor em ambos os servidores:

  • MIRROROFFSET
  • MIRRORPATH

Configuração do Physical-log

O Physical-log deve ser idêntico em ambos os servidores. Os seguintes parâmetros do ONCONFIG devem ter os mesmos valores em cada servidores:

  • PHYSBUFF
  • PHYSFILE

Dbspace e dispositivo de backup para logical-log

Você pode especificar diferentes dispositivos para o servidor primário e secundário.

Se você usar o ON-Bar, configure os parâmetros de configuração do ON-Bar com os mesmos valores em ambos os servers. Para informações dos parâmetros do ON-Bar veja o IBM Informix Backup and Restore Guide.

Se você usa o ontape, o tamanho e o bloco do dispositivo devem ser idênticos. A seguir os parâmetros do ONCONFIG que devem ser o mesmo valor em ambos os servidores:

  • LTAPEBLK
  • LTAPESIZE
  • TAPEBLK
  • TAPESIZE

Configuração do Logical-log

Todos os registros de logs são replicados para o servidor secundário. Você pode configurar o mesmo numero de Logical-log e também com o mesmo tamanho em ambos os servidores. A seguir os parametros do ONCONFIG que devem ser o mesmo valor em ambos os servidores:

  • LOGBUFF
  • LOGFILES
  • LOGSIZE
  • DYNAMIC_LOGS

Logical-logs que são adicionados dinamicamente no servidor primário são replicados automaticamente para o servidor secundário. Embora o valor de DYNAMIC_LOGS no servidor secundário não tem nenhum efeito, DYNAMIC_LOGS mantem em sincronia com os valores do servidor primário.

Parâmetros de configurações do HDR

Os seguintes parâmetros de configuração do HDR devem ser definidos com valores iguais em ambos o servidores:

  • DRAUTO
  • DRINTERVAL
  • DRTIMEOUT

Para servidores secundários em cluster de alta disponibilidade HDR, RSS e SDS, Logical-log  em tabelas temporárias devem sempre ser desativado, definindo o parâmetro de configuração TEMPTAB_NOLOG a 1.