Guia para otimização de entrega de aplicativos e balanceamento de carga de servidor para o mercado de PME Introdução As pequenas e médias empresas (PME) de hoje passam pela mesma evolução de TI que suas equivalentes corporações, porém, em escala reduzida. Para PMEs, confiabilidade, escalabilidade flexível, desempenho e gerenciamento fácil são tão essenciais para a infraestrutura de seus websites quanto para os de grandes corporações. É justo dizer que essas capacidades são um imperativo operacional importante para empresas de todos os tamanhos. As PMEs podem ganhar eficiênica e vantagem competitiva ao adotar as tecnologias de rede mais apropriadas. No entanto, sem os sistemas apropriados em vigor, elas irão sofrer com desempenho fraco e estarão em clara desvantagem competitiva. Por essa razão, escolher os controladores de entrega de aplicativo mais apropriados e os produtos certos de balanceamento de carga de servidor é crítico para garantir infraestrutura de website eficiente e eficaz para suprir as necesidades atuais, enquanto garantem o caminho certo em upgrades para as exigências futuras do negócio. As necessidades das PMEs para entrega de aplicativo e balanceamento de carga de servidor Até recentemente, mesmo o mais básico dos balanceadores de carga de servidor era caro demais para pequenas e médias empresas. Hoje, avançados controladores de entrega de aplicativo e balanceadores de carga de servidor não apenas são financeiramente viáveis, como também oferecem às PMEs infraestrutura pronta e custo-eficiente, graças à consolidação de balanceadores de carga para Camadas 4-7, distribuição de conteúdo e capacidades de offload de servidor como SSL, cachê e compressão de dados. Para grandes organizações (empresas com 1.000 funcionários ou mais), integrar infraestruturas de rede de primeira linha é corriqueiro. Mas, para pequenas e médias empresas, primeira linha não se associa à implementação de redes com funções corporativas específicas e produtos caros, mas à implementação de produtos criados com objetivo, com funções explícitas, desempenho, confiabilidade e escalabilidade criadas especialmente para o mercado de PME. De forma geral, negócios de todos os tamanhos estão inclinados a comprar produtos de grandes marcas. No entanto, vendedores menores, que oferecem produtos na mesma categoria, podem entregar as funções, a confiabilidade e o desempenho perfeitos exigidos por PMEs, com os mesmos benefícios e por preços mais baixos. Para o mercado corporativo, produtos de primeira linha vêm com alto Custo Total de Propriedade (CTO), já que a implementação de produtos de diversos fabricantes exige treinamento adicional, manutenção e suporte. A KEMP pode ajudar PMEs a reduzirem CTO, e ajuda-las a construir infraestrutura web e de aplicativo confiável, com alto desempenho e escalabilidade. Os produtos da KEMP têm alto valor em custo-desempenho para PMEs. Nossos produtos são especialmente construídos para pequenas e médias empresas por um preço acentuadamente mais baixo do que as grandes marcas vendedoras de ADC e SLB, que desenvolvem funções que clientes corporativos podem usar. Soluções comprovadas para entrega de aplicativo e balanceamento de carga de servidor custo-eficiente e confiável Outros fornecedores oferecem controladores de entrega de aplicativo e balanceadores de carga de servidor, mas os produtos da KEMP têm o melhor valor custo-desempenho determinado por ricas funções, escalabilidade, alta disponibilidade, desempenho e facilidade de
gerenciamento por um preço custo-eficiente de acordo com as necessidades de pequenas e médias empresas. Aplicativos web Até pouco tempo atrás, os negócios tinham sistemas e serviços separados para se comunicar e realizar transações com clientes, parceiros e funcionários. Hoje, devido à aceitação e acessibilidade generalizada da Internet, o verdadeiro poder da rede é utilizado. Os aplicativos tradicionais, como processamento de pedidos, folha de pagamento e gerenciamento de clientes foram integrados em aplicativos web completos de cadeia de suprimento. Esses novos aplicativos web, agora, unificam e alinham processos de negócio que antes vinham de clientes monolíticos/ servidor de aplicativos de negócio. Uma boa notícia pra PMEs, já que os aplicativos baseados em web oferecem potencial para reduzir despesas com hardware, reduzir tempo de mercado e custos com manutenção. Não é moleza Muitas organizações que implementam aplicativos baseados em web enfrentam uma diversidade de desafios desde a implementação inicial até produção. Por exemplo, é possível encontrar problemas quando seus servidores não conseguem lidar com o número de acessos em seu website. As fontes do problema são, invariavelmente, devido ao alto volume de tráfego conectado à rede e limitações relacionadas aos recursos de servidor. Apesar dos crescentes orçamentos para upgrades de servidores e redes, os aplicativos web podem não entregar os aprimoramentos esperados de desempenho, escalabilidade e eficiência. Infraestrutura de TI E-commerce é conduzido usando websites baseados em transações, que podem ser extremamente complexos e caros para gerenciar. Um site típico de e-commerce é conectado por roteadores que transmitem tráfego por firewalls, que enviam o tráfego para os controladores de entrega de aplicativo (a nova geração de balanceadores de carga de servidor), que, por fim, direcionam os usuários aos servidores apropriados. Produtos de otimização de rede e entrega de aplicativo distribuem o tráfego para diversos servidores, geralmente conectados aos servidores de banco de dado. Se um desses componentes falhar, o pior cenário possível seria o site todo sair do ar. Geralmente, o que acontece é um pedido de usuário se atrasar ou uma transação de usuário falhar. A Internet é uma rede altamente resiliente. No entanto, não foi desenvolvida com as demandas do comércio moderno em mente. Com o atual uso da Internet, um breve atraso pode custar centenas ou milhões de dólares para um negócio. Mesmo que novos aplicativos baseados em web sejam desenvolvidos com isso em mente, tanto a Internet quanto os recursos de servidor podem ser uma obstrução. A Internet não diferencia transações críticas ao negócio de um website tranquilo, e não garante qualidade de serviço para aplicativos. Se você tiver orçamento ilimitado de TI para servidores, sistemas, banda e pessoal para gerenciar e monitorar sua infraestrutura de website, talvez fique bem, mas, para praticamente todas as organizações, esse cenário é absurdo. Soluções de entrega de aplicativo As soluções de entrega de aplicativo são desenvolvidas para lidar com os desafios associados à complexidade, ao desempenho, à escalabilidade e à segurança de infraestrutura de website. As soluções de entrega de aplicativo são bem diversificadas. Elas podem ser chamadas de controladores de entrega de aplicativo (ADC), balanceadores de carga de servidor (SLB), dispositivos de front-end de aplicativo (AFE), gerenciadores de tráfego de aplicativo, front-end web, distribuidores de conteúdo e switches de aplicativo. A fim de evitar confusão, este artigo irá focar em soluções de data center e se referir as soluções de entrega de aplicativo como controladores de entrega de aplicativo (ADC). Os ADCs de hoje, na verdade, se desenvolveram a partir dos balanceadores de carga de servidor, que surgiram no fim da década de 1990. Os ADCs oferecem a habilidade de direcionar usuários da Internet aos servidores mais acessíveis e com melhor desempenho. Caso um dos servidores (ou aplicativos naquele
servidor) se torne inacessível por qualquer motivo, o ADC irá desativar o servidor ou aplicativo, enquanto redireciona, automaticamente, os usuários para outros servidores em funcionamento. Esse processo passa despercebido pelo usuário e é essencial para o atendimento do cliente. Nos últimos cinco anos, a entrega de aplicativos emergiu como uma das mais importantes tecnologias na solução de problemas de desempenho e acessibilidade para aplicativos baseados em Internet. Além disso, ao utilizar diversos algoritmos de balanceamento de carga, um ADC pode distribuir usuários para servidores que oferecem o melhor desempenho possível. O ADC pode, dinamicamente, interrogar elementos-chave do servidor, como número de conexões concomitantes e utilização de CPU/memória. Para melhorar e assegurar a experiência do usuário, ADCs mais avançados oferecem aceleração/offload de SSL. A aceleração de SSL no ADC permite que você descarregue o handshake de SSL e processos de criptografia/decriptação nos servidores. Essa descarga melhora, significativamente, o desempenho do servidor, enquanto reduz tempo e custos associados com o gerenciamento do certificado SSL do servidor. A mais significativa demanda do mercado virá da integração com aplicativos Web 2.0. Essa demanda será atendida pelos ADCs. Além da aceleração de SSL, existem outros três elementos primários para aceleração de aplicativo. Cache de conteúdo armazena dados que provavelmente serão usados novamente e provavelmente não sofrerão alteração, em vez de pedir que computadores recuperem dados da fonte cada vez que forem necessários. Compressão de dados reduz a quantidade de dados cruzando o link comprimindo os dados em pacotes menores, que são, então, combinados em pacotes maiores tornando mais fácil e rápido envia-los pela rede. Os controladores de entrega de aplicativo usam diversas técnicas para distribuir a carga de tráfego entre dois ou mais servidores, roteadores, firewalls e outros recursos de rede para otimizar a utilização de recursos e melhorar o desempenho do website e seu tempo de resposta. A maioria dos ADCs são capazes de oferecer gerenciamento da Camada 4 até Camada 7. A Camada 4 é limitada a pedidos web destinados à Porta TCP 80; portanto, não é possível fazer nenhuma outra diferenciação entre grupos de servidor. No entanto, a Camada 7 usa critério de camada de aplicativo para determinar para onde enviar um pedido. Isso oferece ao controlador de entrega de aplicativo um controle muito mais gradual sobre o encaminhamento de decisões. No diagrama 2, abaixo, usando protocolo HTTP, www.xyz.com/images, pode estar apontando para um servidor diferente, enquanto o www.xyz/shop pode estar direcionado aos servidores de imagens. Diagrama 2: Redireciona usuários para o servidor mais apropriado com base em distribuição da Camada 7. Outro uso exclusivo da Camada 7 para persistência é mantendo persistência de usuário no Microsoft Windows Terminal Services (WTS). O que buscar em um controlador de entrega de aplicativo As funcionalidades listadas abaixo devem ser o critério que uma empresa pequena ou média busca ao escolher uma solução de rede e de entrega de aplicativo. Alta disponibilidade (hot standby) Como todo o tráfego de chegada deve passar pelo controlador de entrega de aplicativo, caso eles falhem, o grupo de servidores e todo o site ficarão inacessíveis. Para lidar com isso, a maioria dos fornecedores suportam configurações redundantes. Geralmente, uma configuração standby (ou redundante) é suportada às vezes referida como HA (Alta Disponibilidade). A maioria dos sites utiliza pelo menos um par de HA já que seria arriscado implementar múltiplos servidores web para redundância e escalabilidade, apenas para perder o site inteiro em caso de falha no hardware de ADC. Caso um dos produtos LoadMaster caia, a unidade em standby envia uma notificação SMNP ao administrador.
Balanceamento de carga na Camada 4 Os controladores de entrega de aplicativo oferecem múltiplos métodos de Camada 4 baseados em IP para distribuir tráfego de usuário para os servidores. Esses métodos podem incluir Round Robin, Weighted Round Robin, Least Connection, Weighted Least Connection, Chained Failover e Server Resource-Based. A ponderação (weighting) permite que o administrador determine um peso mais alto (ou mais baixo) para servidores reais, para oferecer melhor controle sobre a distribuição de tráfego. Por exemplo, se dois servidores web forem baseados em plataforma Intel P3 e você acrescentar um novo servidor baseado em Xeon dual, quadcore, com 16GB de RAM, você pode designar o novo servidor com peso mais alto, enviando, assim, 2, 3 ou 100 vezes mais tráfego para o novo servidor. Enquanto métodos de balanceamento de carga de Camada 4 são suficientes para muitos casos de tráfego de Internet com pouco volume, um grande número de sites exige uma abordagem muito mais gradual para a distribuição de tráfego, o que pode ser alcançado somente por meio de métodos de balanceamento de carga de alto nível, como distribuição de conteúdo na Camada 7. Distribuição de conteúdo na Camada 7 Distribuição de conteúdo se refere à habilidade de distribuir (ou balancear carga) pedidos de usuários entre servidores baseados em payload de Camada 7. Mais comumente, isso é realizado com o exame do conteúdo da página (como URL) e distribuição os pedidos para os servidores ou grupos de servidores apropriados. Por exemplo, www.xyz.com/images pode estar direcionado para um servidor que lida com gráficos, enquanto www.xyz.com/shop pode estar direcionado para um servidor de transações. Isso oferece melhor sintonia de desempenho e flexibilidade de aplicativo. Além disso, se seu aplicativo web fizer uso intenso de cookies, um controlador de entrega de aplicativo habilitado para camada 7 pode ser um modelo melhor para alcançar persistência de servidor. Persistência de IP (Persistência na Camada 4) Persistência (outras vezes referida como afinidade de servidor ou perdurabilidade ) é mais bem compreendido se olharmos para o exemplo do carrinho de compras. O carrinho de compras, como utilizado pela grande maioria dos sites de e-commerce, é um depósito lógico para os itens selecionados pelo cliente enquanto faz suas compras em uma loja online. Os itens selecionados, de forma geral, residem no servidor em que o cliente se conecta inicialmente e que apresenta o conteúdo ao cliente durante a sessão. Se, em algum momento durante a sessão, o cliente é transferido para outro servidor (um servidor que não compartilha os dados da sessão), o carrinho de compras do cliente é perdido e a experiência de compra, arruinada. A persistência é um método que garante que, por um determinado tempo, o usuário volte sempre para o servidor onde os dados estão localizados. Existem diversas formas como a persistência pode ser alcançada. O mecanismo de persistência foi inicialmente implementado por balanceadores de carga baseados em endereço IP de origem. Usando IP de origem, os balanceadores de carga identificam o usuário por seu endereço IP de origem e o mantém preso ao servidor apropriado usando esse identificador. Este método logo se comprovou falível devido ao efeito de proxy de servidor e NAT (networkaddress translation). Quando proxy e NAT são usados, não existe uma forma segura de associar um usuário a um endereço IP. Em vez disso, muitos usuários podem ser representados por um mesmo endereço IP ou o endereço IP de um mesmo usuário pode mudar durante um ciclo de sessão. Devido a esse efeito predominante, a persistência na Camada 7 (ou Cookie) é muito mais confiável e é mais comumente oferecida por controladores de entrega de aplicativo. Persistência na Camada 7 (Persistência em Cookie) Controladores avançados de entrega de aplicativo em Camada 7 oferecem a habilidade de inspecionar dados na camada do aplicativo. Com isso, temos o mecanismo de persistência conhecido como Persistência em Cookie. A persistência em cookie usa cookie do navegador para identificar o usuário de forma única. Tanto o aplicativo quanto o controlador de entrega de aplicativo em si pode servir cookies ao usuário no início de uma sessão e o navegador do usuário devolve o cookie, automaticamente, durante cada hit sucessivo. Ao rastrear as informações do cookie, o controlador de entrega de aplicativo é capaz de determinar, com
precisão, qual servidor deve receber o pedido subsequente. A persistência em cookie é o método mais seguro de alcançar persistência. Aceleração SSL Se o seu site contém elementos transacionais, as chances são de que uma porção ou todo o site usa SSL para criptografar e assegurar essas transações. No passado, SSL era conduzido no mesmo servidor do conteúdo. No entanto, como o processo SSL eleva significativamente o desempenho geral do servidor, lidar com SSL no servidor era menos que ideal, para dizer o mínimo. Diversas opções existem para auxiliar o processo SSL no nível do servidor incluindo a instalação de cartões de aceleração SSL, que são criados para realizar offload de handshake SSL intensos no CPU e configuração de sessão e desconexão, mas essa solução apresenta outras complexidades e não ajuda na distribuição de conteúdo na Camada 7 e persistência. Fica claro que a melhor forma de realizar offload do processo SSL é pelo controlador de entrega de aplicativo não no servidor. Uma vez que o SSL é movido para o ADC, todos os pedidos HTTPS são terminados no ADC, decodificados e encaminhados para o servidor real apropriado via HTTP. Isso oferece diversas vantagens, incluindo agregação de certificado SSL (agora seria necessário apenas um certificado, que reside no LoadMaster, em vez de um certificado para cada servidor), mas, principalmente, permite a decodificação do conteúdo fornecendo, assim, ao controlador de entrega de aplicativo, a habilidade de executar distribuição de conteúdo e persistência na Camada 7 de todo o tráfego que se origina como HTTPS. Usando persistência com SSL Incapazes de confiar em endereço IP de origem e impossibilitados de inspecionar cookies durante uma sessão SSL, os fornecedores de controladores de entrega de aplicativo tiveram de criar um método que oferecesse persistência em um ambiente SSL. Felizmente, SSLv3 oferece uma forma de fazer isso. O SSLv3 transfere o ID da sessão SSL, um identificador de 32 byte único de sessão, para fora da porção codificada do dado para uma porção limpa. Os controladores de entrega de aplicativo são, então, capazes de ler esse identificador único e balancear o tráfego para o servidor apropriado com base nesse identificador previsível. Esse método funcionou bem até que a Microsoft lançou a versão 5.0 do Internet Explorer. A partir do IE5, a Microsoft mudou o comportamento do SSL para forçar a renegociação de uma nova sessão SSL a cada dois minutos. O que significa que todos os usuários do IE5 e novos usuários teriam o ID das sessões SSL alterados a cada dois minutos, quebrando o único método seguro de persistência disponível. Ao juntar o acelerador SSL com um controlador de entrega de aplicativo, mais uma vez foi possível oferecer persistência confiável pela decodificação do conteúdo SSL, para que o ADC possa inspecionar os dados novamente. Quando o tráfego SSL chega ao controlador de entrega de aplicativo, é redirecionado para uma função de offload de SSL. O acelerador SSL decodifica o conteúdo completo, incluindo qualquer cookie que tenha sido enviado pelo navegador, e o envia de volta para o ADC. Nesse ponto, os dados estão limpos e o controlador de entrega de aplicativo pode inspecionar os cookies, o URL, o URI, o tipo de navegador etc. Gerenciamento de diretório de sessão, persistência e balanceamento de carga em Windows Terminal Services Os ADCs podem oferecer suporte completo ao Windows Terminal Services 2003 e Windows Server 2008. O recurso de monitoramento do ADC fornece dado tanto sobre memória de servidor quanto CPU, garantindo que a experiência do usuário receba o mais eficiente balanceamento de carga possível entre cada servidor. O ADC se integra ao diretório de sessão WTS, oferecendo uma reconexão segura quanto desktop remoto se desconecta do servidor. Um controlador de entrega de aplicativo que suporta persistência em camada 7 com base em RDP pode incorporar reconexão de sessão de cliente, o que pode ser utilizado sem necessidade do serviço Diretório de Sessão ser instalado. Isso ajuda a simplificar a infraestrutura de TI e oferecer benefícios de redução de custos.
Número de portas LAN É importante observar que o número total de portas não tem nada a ver com o número de servidores que o controlador de entrega de aplicativo é capaz de suportar. Usando seu hub ou switch de camada 2/3 existente, você pode suportar muito mais servidores do que o número de portas provisionadas no ADC. Na verdade, usando o que às vezes é chamado de configuração simples, é possível balancear carga entre até 100 servidores físicos com um único controlador de entrega de aplicativo. Maximum Real Servers Maximum Real Server se refere ao número de servidores físicos que um ADC pode suportar. Dependendo do modelo do controlador de entrega de aplicativo, você terá uma limitação no número de servidores físicos suportado por um servidor virtual (VIP). Porém, é muito provável que você exceda a capacidade de sua conexão de Internet bem antes de alcançar o limite de servidores suportado pelo ADC. Um controlador de entrega de aplicativo consiste tem um servidor virtual (também chamado de cluster virtual, IP virtual ou VIP) que, por sua vez, consiste em um endereço IP e uma porta. Esse servidor virtual está ligado a um número de servidores físicos (reais) dentro de um parque de servidores. No ADC, o servidor virtual (VIP) é, geralmente, um endereço IP público que responde os pedidos de usuários. Normalmente, o balanceamento de carga, a distribuição de conteúdo e a persistência dominam e os métodos são designados com base em cada VIP. No caso dos servidores reais, ter um bom número de VIPs suportados oferece mais flexibilidade na arquitetura e no design do site ou aplicativo já que múltiplos VIPs podem ser direcionados para o mesmo conjunto de servidores físicos. Um ADC robusto pode suportar até 256 VIPs. Máximo de servidores reais por VIP Muitos vendedores de controladores de entrega de aplicativo determinam um limite para a quantidade de servidores reais que pode ser conectados um único VIP. Um número muito baixo de servidores reais por VIP pode inibir o design e a arquitetura de certos aplicativos. Um bom controlador de entrega de aplicativo deve suportar até 100 servidores físicos por VIP. Taxa de transferência Enquanto a maioria dos vendedores fornece uma capacidade máxima teórica de banda da interface Ethernet, esse número tem muito a ver com a taxa de transferência real dos controladores de entrega de aplicativo, já que esse número é altamente dependente do número e tipo de regras que o ADC tem de analisar, conforme ele decide sobre como lidar com o pacote. Por exemplo, se o ADC tem de tomar uma decisão de balanceamento de carga com base em conteúdo na Camada 7, a latência adicional associada a esse processo pode ter um impacto significativo no desempenho geral e na taxa total de transferência. Um dispositivo controlador de entrega de aplicativo de qualidade irá utilizar uma arquitetura moderna de hardware para permitir que ele mantenha desempenho excelente na Camada 7. Maximum TPS SSL TPS se refere ao número de transações SSL que um ADC consegue realizar por segundo. Uma transação SSL inclui o processamento de grandes quantidades de dados associados com a troca da chave SSL e com a configuração e interrupção da conexão SSL. Um controlador de entrega de aplicativo que inclui ASIC para realizar offload de SSL no CPU principal irá entregar melhor desempenho. Geralmente, os cartões de ASIC são bem caros e a maioria dos fornecedores cobra uma taxa extra pelas licenças de TPS adicionais e/ou pela adição de ASIC SSL. É importante encontrar um fornecedor cuja lista de preços já reflita o máximo de TPS SSL. Isso garante que não exista taxa extra por licenças TPS ou placas de processador auxiliar. No entanto, tenha em mente que no mínimo do desempenho SSL, a principal vantagem de ter offload SSL no ADC é a habilidade de decodificar pacotes HTTPS e realizar o balanceamento de carga e tomar decisões de persistência na Camada 7.
Resposta Direta do Servidor (DSR) Em alguns aplicativos, pode ser desejável (ou exigido) que os servidores físicos respondam, diretamente, aos pedidos do usuário sem ter de passar pelo controlador de entrega de aplicativo. O principal benefício de usar a Resposta Direta do Servidor (DSR) é que, ao contornar o ADC, os servidores conseguem transferir grandes quantidades de dados (como streaming de vídeo, páginas pesadas e transferência de arquivos) diretamente para o usuário, evitando qualquer latência que possa ser associada a um controlador de entrega de aplicativo e, assim, aprimorar o desempenho do aplicativo ou site. Enquanto um ADC pode suportar DSR, devemos destacar que, como DSR é um função de Camada 4, qualquer função de Camada 7 (como persistência de cookie) não será disponibilizada com tal configuração. Transparência Um controlador de entrega de aplicativo é, normalmente, configurado como um dispositivo NAT. Isso implica que, quanto o ADC se comunica com um servidor real, o endereço IP cliente apresentado ao servidor é o do controlador de entrega de aplicativo e não o do usuário real que faz o pedido. Em alguns ambientes, isso pode representar um problema, já que o endereço IP original do cliente não aparece nos logs do servidor. Para solucionar esse problema, alguns controladores de entrega de aplicativo oferecem uma função chamada Transparência que oferece, aos administradores, uma forma de preservar o endereço IP do cliente nos logs do servidor. Algumas trocas importantes devem ser realizadas na arquitetura se a transparência for obrigatória, portanto, por favor, consulte o manual do ADC ou entre em contato com o fornecedor para assistência. Compressão HTTP A Compressão HTTP reduz a quantidade de dados que são transferidos de objetos HTTP utilizando compressão gzip, disponível em todos os navegadores modernos. A compressão HTTP permite que os controladores de entrega de aplicativo comprimam a carga útil de cada pacote. De modo geral, ela reduz o consumo de banda de rede sem degradar a qualidade do conteúdo e melhorando a experiência geral do usuário-final. A compressão HTTP rodando em um controlador de entrega de aplicativo reduz a carga dessa intensa tarefa no processador dos servidores. Cache HTTP Os controladores de entrega de aplicativo com capacidade de cache servem como cache de proxy, armazenando dados selecionados em servidores de origem para acelerar a entrega ao usuário. A combinação do cache com a compressão pode entregar benefício em dobro, porque dispositivos podem devolver objetos pré-comprimidos no cache, em vez de busca-los nos servidores de origem. O cache pode aumentar significativamente as taxas de transação e reduzir tempo de resposta, enquanto libera servidores para realizarem outras tarefas. Protocolos que conversam, como HTTP, frequentemente exigem a criação e a interrupção de conexões, criando utilização desnecessária de recursos nos servidores. Os controladores de entrega de aplicativo com capacidade de cache permitem a reproposta de recursos relacionados a conexões para lógica de negócio mais relevante. Prevenção de intrusos Para melhorar a segurança, um controlador de entrega de aplicativo com Sistema de Prevenção de Intrusão (IPS) oferece proteção em linha de banda e servidores ativando a mitigação de ataques e o isolamento de servidores em tempo real. A prevenção de intrusão oferece alerta de intrusão em tempo real. Balanceamento de carga baseado em recurso O balanceamento de carga baseado em recurso permite o uso de linguagem de script para oferecer métodos customizados de balanceamento de carga, manipulação arbitrária de tráfego e mais.
Resumo Para PMEs e fornecedores de hospedagem gerenciada, a complexidade e a natureza dinâmica de sites de e-commerce são as principais causas que levam ao fraco desempenho dos sites e períodos de inatividade não planejados. Pequenas e médias empresas, assim como prestadores de serviços, estão cada vez mais cientes da necessidade de proteger esses sites vitais, porém, vulneráveis. No entanto, a aquisição de mais dispositivos, mais complexidade e mais soluções de capacidades únicas não é a resposta. A otimização da entrega de aplicativos entre usuário-final e diversos equipamentos de data center, fornecendo facilidade de gerenciamento, acesso rápido aos aplicativos e conteúdo e segurança dentro de uma plataforma coesa é obrigatória. A complexidade associada à tecnologia necessária para gerenciar infraestrutura web dentro de PMEs e serviços de hospedagem gerenciada trouxe muitos novos desafios que as equipes de TI devem superar. As novas e variadas tecnologias implementadas dentro dos data centers são, geralmente, mais do que apenas um servidor web e podem, facilmente, exceder as necessidades de gerenciamento, desempenho e escalabilidade que essas organizações exigem. Tudo combinado com o fato de que o acesso seguro e imediato nunca foi uma preocupação mais urgente do que agora, e, ainda assim, muitos websites não possuem a infraestrutura necessária para entregar a segurança, a confiabilidade e o desempenho apropriados.