Essas estratégias são recomendações, mas todos os sistemas possuem requisitos exclusivos, portanto, deve-se discutir tais estratégias com o seu administrador do banco de dados e o administrador dos serviços de informações de internet (IIS) enquanto sua arquitetura é planejada.
As opções de HA estão disponíveis para o PI Coresight nos níveis de servidor do banco de dados e do aplicativo. Cada uma dessas opções possui seus próprios benefícios.
As opções de banco de dados incluem: • Armazenamento em cluster • Espelhamento
• Grupos de disponibilidade AlwaysOn • Réplica transacional
As opções de servidor de aplicativo do PI Coresight incluem: • Equilíbrio de carga de rede (NLB)
• Roteamento de solicitação de aplicativo (ARR)
• NLB e ARR em uma configuração de failover ativa/passiva • NLB e ARR em uma configuração de failover ativa/ativa
Opções de nível de banco de dados
Usando a HA no nível de banco de dados evita que o banco de dados PI Coresight no Microsoft SQL Server torne-se um único ponto de falha.
Deve-se implementar a HA para o banco de dados do PI Coresight da mesma maneira da aplicação da HA para qualquer outro banco de dados do SQL Server. A Microsoft fornece uma descrição geral das suas opções de implementação de HA para MS SQL Server no artigo Visão geral das soluções de alta disponibilidade do SQL Server (HTTP://
MSDN.MICROSOFT.COM/EN-US/LIBRARY/MS190202.ASPX).
Após a conexão, um banco de dados replicado age da mesma maneira que o banco de dados substituído, portanto, a única alteração de configuração exige tornar o aplicativo do PI Coresight ciente do banco de dados replicado. Faça isso ao especificar a sequência de conexão no arquivo web.config. Por exemplo:
connectionString = "Data Source=myPrimaryServer;Failover Partner=mySecondaryServer;
Initial Catalog=myDataBase;Integrated Security=True; Application Name="Coresight Web Service""
O arquivo web.config está localizado em um desses diretórios a seguir: %pihome64%\Coresight\Services for versions 1.x
%pihome64%\Coresight for versions 2.x
Opção de HA do SQL Server Vantagens Desvantagens Armazenamento em cluster • Permite acesso integral de
leitura e gravação para o banco de dados do PI Coresight.
• Não é necessária a ressincronização. Os membros de cluster sempre usam a última cópia compartilhada do banco de dados.
• Exige um investimento inicial significante no hardware do cluster.
• Pode ser lento ao executar o failover entre os membros do cluster (comparado ao espelhamento).
• Somente uma cópia do banco de dados.
• A distância entre os nós é limitada em alguns metros, pois compartilham uma unidade física.
Espelhamento • Permite acesso integral de leitura e gravação para o banco de dados do PI Coresight.
• Tempo de failover rápido (comparado ao
armazenamento em cluster do SQL).
• Duas cópias do banco de dados no hardware independente.
• Os membros podem ser separados fisicamente por uma longa distância.
• Exige um terceiro "servidor testemunha" para o failover automático.
• Se executar em um modo assíncrono, o banco de dados de espelho pode não estar sempre atualizado.
Grupos de disponibilidade
AlwaysOn • Permite acesso integral deleitura e gravação para o banco de dados do PI Coresight.
• Tempo de failover rápido (comparado ao
armazenamento em cluster do SQL).
• Duas cópias do banco de dados no hardware independente.
• Nenhum servidor testemunha é necessário.
• O SQL Enterprise é necessário para utilizar os grupos de disponibilidade.
Réplica transacional • Duas cópias dos dados no
hardware independente. • O failover não é suportado.• O equilíbrio de carga não é suportado.
• Nenhuma proteção de dados replicados foi alterada.
As opções de HA do servidor de aplicativo do PI Coresight
A HA no nível do servidor de aplicativo pode fornecer equilíbrio de carga e tolerância a falhas. A tabela a seguir esboça alguns prós e contras para as implementações de equilíbrios de carga de rede diferentes (NLB) e o roteamento de solicitação de aplicativo (ARR). Para uma discussão mais detalhada da configuração, dos benefícios e das desvantagens para esses cenários,
consulte o artigo do IIS Arquivando a alta disponibilidade e escalabilidade - ARR e NLB Opções de alta disponibilidade para o PI Coresight
(HTTP://WWW.IIS.NET/LEARN/EXTENSIONS/CONFIGURING-APPLICATION-REQUEST- ROUTING-(ARR)/ACHIEVING-HIGH-AVAILABILITY-AND-SCALABILITY-ARR-AND-NLB). A tabela a seguir resume os benefícios e as desvantagens de cada opção de HA do servidor de aplicativo do PI Coresight.
As opções de HA do servidor de
aplicativo do PI Coresight Vantagens Desvantagens
Roteamento de solicitação de
aplicativo (ARR) • Divide a carga de acesso dedados no servidor de aplicativo.
• Outros recursos estão disponíveis para permitir que o ARR atue como um proxy reverso, se desejar.
• Não fornece uma HA verdadeira, pois o nó de ARR permanece um único ponto de falha.
• A escalabilidade é limitada, pois o tráfego é canalizado através de um único nó. Equilíbrio de carga de rede (NLB) • Divide a carga de acesso de
dados no servidor de aplicativo.
NLB e ARR (ativo/passivo) • Fornece o HA verdadeiro, já que não há um único ponto de falha.
• Outros recursos estão disponíveis para permitir que o ARR atue como um proxy reverso, se desejar.
• O investimento maior exigido, em termos de configuração e número de máquinas disponíveis necessárias.
NLB e ARR (ativo/ativo) • Fornece o HA verdadeiro, já que não há um único ponto de falha.
• Fornece a escalabilidade verdadeira, pois o tráfego não é canalizado através de um único nó.
• Outros recursos estão disponíveis para permitir que o ARR atue como um proxy reverso, se desejar.
Para obter maiores informações sobre a alta disponibilidade e o sistema PI, consulte a seção Alta disponibilidade, no servidor PI na Biblioteca ativa de PI (http://livelibrary.osisoft.com/ LiveLibrary/web/pub.xql?action=publist_home).