Balanceamento de carga entre serviços (LoadBalance)

Quando existe uma grande quantidade de usuários que utilizam o sistema, e o servidor (hardware) não possui uma configuração ideal para comportar todas as conexões simultaneamente, mas há mais de um servidor disponível, pode-se configurar balanceamento de carga de conexões, para permitir a escalabilidade da aplicação. Para que isto seja possível, "nomeamos" um servidor intitulado de "servidor Master" que será o responsável por administrar o balanceamento. Configurando o servidor Master O único arquivo de configuração (xxxsrv.ini) que será alterado com as configurações abaixo é o do servidor Master, pois é ele quem administrará o balanceamento de carga de conexões. Todos os usuários se conectarão inicialmente ao servidor Master, e é este quem efetuará o balanceamento de carga das conexões para os outros servidores. Nos arquivos de configuração (*.ini) dos outros servidores será alterado apenas a chave "RootPath", para que eles peguem a mesma base de dados do servidor Master. [ServerNetwork] Servers=SERVER2, SERVER3 --> NÃO INFORME O NOME DO SERVIDOR MASTER MasterConnection=0 --> O SERVIDOR MASTER NÃO RECEBE CONEXÃO [SERVER2] Type=TCPIP Server=172.16.77.42 Port=1234 Connections=1 [SERVER3] Type=TCPIP Server=172.16.75.62 Port=1235 Connections=1 Configuração dos outros servidores Conforme citado acima, nos demais servidores a única coisa que será alterada é a chave " RootPath" do arquivo de configuração do TOTVS Application Server. Para isso, o diretório raiz (P10), do servidor Master, deve ser compartilhado com direitos apenas para um usuário que será usado por todos os serviços. Assim, os outros usuários não conseguirão acesso a este diretório. Isto é necessário para que todos os servidores exerguem a mesma base de dados. Supondo que a base de dados esteja no servidor Master, os arquivos de configuração (*.ini) ficariam assim: [Environment] SourcePath=C:\XXX\APO RootPath=\\SIGAMASTER\XXX\AP_DATA\ --> Veja que a raiz está sendo apontada para o servidor Master. StartPath=\SIGAADV\ ou \SYSTEM\ (as demais configurações continuam iguais) Observações Cada servidor deverá ter o seu build e repositório, sendo que a base de dados fica centralizada no servidor Master ou no servidor de banco de dados. O balanceamento de carga de conexões é monoplataforma para o TOTVS Application Server. Isso significa que o MASTER e todos os SLAVES devem rodar no mesmo sistema operacional. Quando for realizada qualquer atualização de build e o repositório no servidor Master, a mesma alteração deverá ser feita nos outros servidores. Um mesmo usuário Windows deve ter direitos na pasta compartilhada (RootPath) e deverá ser um usuário Administrador, para que possa ser associado ao serviço de cada servidor. Para verificar onde os usuários estão conectados, basta utilizar a aplicativo TOTVS Monitor em cada servidor. Crie seções [TCP] no arquivo de configuração, do TOTVS Smart Client, para receber conexão dos slaves (TCP1, TCP2, TCP3 e TCPN). [TCP1] Server=Slave1 Port=1237 [TCP2] Server=Slave2 Port=1239 [TCP3] Server=Slave3 Port=1241 Ao abrir o TOTVS Monitor, informe qual comunicação [TCP] que deseja verificar as conexões. O nome do ambiente e portas de comunicação deve ser idêntico para todos os servidores. Separe em um servidor dedicado, um TOTVS Application Server para o ambiente de compilação: compilação é uma operação crítica, exclusiva, que não deve ser executada no mesmo serviço do TOTVS Application Server que está atendendo conexões de usuários do TOTVS Smart Client e ambiente de produção. No caso de balanceamento de carga de conexões em schedule, deve-se escolher um slave para receber a conexão. Lembre-se que o servidor Master NÃO recebe conexões. O valor da chave Connections determina a distribuição de conexões entre os slaves usando RAZÃO MATEMÁTICA (Exemplo: 1:2:1) O valor de RootPath=\\SIGAMASTER\XXX\AP_DATA\ deve ser a mesma para todas as instâncias para os ambientes [Environment] de mesmo nome. Para mais informações, consulte a documentação da seção [ServerNetwork]. Reserve 2 GB para cada TOTVS Application Server criado que pode ser na mesma máquina (desde que tenha capacidade para isso). No ambiente de balance cada ambiente deve ter seu RPO (todos iguais). NÃO compartilhe RPO em rede, pelos seguintes motivos: Em casos conhecidos os logs mostram que o sistema operacional está causando os erros de comunicação nos servidores de aplicação e não nas estações. As mensagens que as estações enviam no momento de uma nova conexão mostram que foi a parte servidora da operação que cortou a conexão de rede. Os servidores de aplicação fazem leitura intensiva dos RPOs quando executam o ERP, pois neles estão compiladas todas as regras de negócio, se o RPO é compartilhado em rede, tem como resultado: Degradação na performance de execução dos servidores de aplicação que utilizam o RPO compartilhado (tráfego de RPO em rede). O aumento do consumo de recursos de rede nos servidores que compartilham RPO, tipicamente, saturam o uso das interfaces de rede, criando uma concorrência de transmissão de dados com as estações que utilizam o TOTVS Smart Client.

CGI

http://www.cgi.br/

Fotos com flash

Confira "Adobe Flash Player 10.3"

Published with Blogger-droid v1.7.4

Windows Server 2003 Standard Edition

GKQCK-YXFH6-M6KQT-K3F88-6VMCD

Benchmark (computação)

    

Em computação, benchmark é o ato de executar um programa de computador, um conjunto de programas ou outras operações, a fim de avaliar a performance relativa de um objeto, normalmente executando uma série de testes padrões e ensaios nele.
O termo "benchmark" é também comumente usado para os próprios programas (de benchmarking) desenvolvidos para executar o processo. Normalmente, benchmarking é associado com avaliação de características de performance de um hardware de computador como, por exemplo, a performance da operação de ponto flutuante de uma CPU, mas há circunstâncias em que a técnica também é aplicável a software. Benchmarks de software são feitos, por exemplo, em compiladores ou sistemas de gerenciamento de banco de dados.
Benchmarks provêm um método de comparação da performance de vários subsistemas dentre as diferentes arquiteturas de chips e sistemas. Benchmarking é útil para o entendimento de como o gerenciador de banco de dados responde sob a variação de condições. Pode-se criar cenários que testam o tratamento de deadlock, performance dos utilitários, diferentes métodos de carregar dados, características da taxa de transição quando mais usuários são adicionados e ainda o efeito na aplicação usando uma nova versão do produto.

Origem: Wikipédia, a enciclopédia livre.

Servidores registrados na Internet

O gráfico abaixo apresenta a evolução do número de máquinas registradas na Internet desde 1994 até hoje. Estamos na casa dos 700 milhões de servidores espalhados pelo mundo, atendendo a toda sorte de solicitações e demandas. Com novas tecnologias e dispositivos sendo adicionados à grande rede a cada dia, estamos certos de que esta curva será cada vez mais crescente.

FIDONET

Foi fundada em 1984.
Era a rede mundial de computadores utilizada para comunicação com os BBS (Bulletin Board System).

Muito popular no início dos anos 90, serviu de inspiração dos recursos e formas de utilização que temos hoje na Internet. Os BBS eram verdadeiros oásis digitais trazendo diversos recursos como em um portal de Internet.

Através dos BBS, um usuário poderia fazer uma conexão via modem e linha telefônica, acessando um sistema, utilizando um programa de terminal, utilizando a FIDONET.  Muitos BBS ofereciam jogos on-line, envio e acesso a arquivos, leituras de notícias, envio e recebimento de e-mails e mensagens para grupos de discussão e salas de bate-papo. Tudo isso utilizando programas.

USENET

É um acrônimo de Users Network (Rede de Usuários). Consistia em um sistema global de discussão na Internet derivado das redes UUCP (Acrônimo de UNIX To UNIX Copy Protocol. É tanto um protocolo quanto um programa).

Este sistema é um dos mais antigos de comunicação entre redes. Ele possibilita a troca de mensagens e opiniões entre usuários interessados no mesmo tema. Como nos Fóruns de Discussão que existem hoje em dia.

Começou a funcionar em 1980. Na época, era chamada de ARPANET para pobres. Ela empregava UUCP para utilização de e-mail e transferência de dados, formando, assim, uma solução denominada grupos de notícias. Qualquer usuário inscrito em um grupo de notícias poderia enviar uma mensagem para seu grupo.

A USENET deu origem ao que conhecemos nos dias de hoje como listas de discussão e fóruns.
Por essa você não esperava?!

Bitnet

A Rede foi criada para envio e recebimentos de e-mails entre Instituições de Pesquisas no mundo todo.

Em 1988, o LNCC (Laboratório Nacional de Computação Científica) no Rio de Janeiro se conectou via link (conexão de dados) de 64kbps à Universidade de Maryland nos Estados Unidos.

Em 1989, chegou a vez do NCE (Núcleo de Computação Eletrônica) da UFRJ se ligar a UCLA, também nos Estados Unidos.

Várias Instituições de Pesquisa e Universidades foram se  interligando por esta rede que só veio a perder força com a popularização do e-mail via Internet . 

Cabe ressaltar que esta rede era fechada, isto é, somente aquelas Instituições de Pesquisa e Educação filiadas poderiam se falar a princípio.

Tapioqueira por ricardomororo no Garmin Connect - Detalhes

Tapioqueira por ricardomororo no Garmin Connect - Detalhes

José Bastos por ricardomororo no Garmin Connect - Detalhes

Passeio Sport Bike
José Bastos por ricardomororo no Garmin Connect - Detalhes