none
Forms Authentication com Load Balancing RRS feed

  • Pergunta

  • Bom dia, Srs!

    Estamos na fase de desenho da aplicação e um dos requisitos técnicos que vamos atender é a utilização de servidores Load Balancing tanto na camada de Apresentação (View) quando na camada de Negócio (Business). Como estamos em Load Balancing é a Session é criada apenas em um nó do servidor e sem replicação (InProc State Server) não iremos utilizar esse recurso do .NET. Quanto a isso, já estamos acostumados e não haverá problema.

    Entretanto, estava pensando em utilizar como opção de autenticação Forms Authentication (que é baseado em "Session") que de acordo com um antigo colega de trabalho funciona sem problemas nesse esquema de servidores. Ainda não tenho as máquinas disponíveis para efetuar os testes conclusivos a respeito, mas estou extremamente tendencioso a usar esse esquema visto que tenho total confiança no profissional que me deu a dica.

    Como não encontrei nenhum material que diz que funciona ou que não funciona, venho recorrer a sapiencia contida no pessoal que frequenta esse fórum e ver se alguém tem alguma ressalva ou sugestão para acrescentar.

    Portanto, alguém tem indícios de que Forms Authentication em aplicações Web não funciona com Load Balancing?

    Muito Obrigado!

    Att.,
    Antonio Carlos

    quinta-feira, 22 de fevereiro de 2007 13:39

Respostas

  • Antonio,

    além da opção padrão de armazenar os dados de sessão no processo do ASP.NET, há também a possibilidade de que a sessão do usuário fique armazenada em servidores de estado ou em banco de dados SQL Server. Isso é ideal para ambientes do tipo Web Farm, no qual há balanceamento de carga entre os servidores. Você disse que não vai usar essa funcionalidade. Entendi certo? Como você vai cuidar disso?

     


    Ricardo Oneda
    http://oneda.mvps.org/blog

    quinta-feira, 22 de fevereiro de 2007 19:07
  • Antonio,

    Nao existe problemas referentes a isso: apesar de outras solucoes comentadas acima sao mais tradicionais. Esse modelos (Out-Of-Proc - ) apesar disso tem suas observacoes, como o rendimento, a validacao do mesma machine key entre os servidores e a serializacao dos objetos que devem ser avaliadas.

    Abs

    FC
    http://sushinetcode.blogdrive.com

    quinta-feira, 22 de fevereiro de 2007 21:26
  • Se você não vai usar um state server, o melhor mesmo é configurar seu NLB para afinidade de sessão. Assim, uma vez o cara se autenticando num servidor, ele só acessa esse mesmo servidor dali em diante. Fica mais fácil e você não tem que se preocupar com nada, nem mesmo que autenticação usa.

     

    Agora, se você não vai ter afinidade de sessão, então ambos os servidores precisam responder no mesmo domínio, o que provavelmente vai acontecer mesmo, já que você vai usar NLB. Também eles precisam ter os machine keys sincronizados, senão o forms authentication de um não vai ser reconhecido pelo outro. E se eles tiverem subdomínios (tipo site.com, algumacoisa.site.com, outracoisa.algumacoisa.site.com) então o endereço do cookie de autenticação tem que apontar pro domínio raíz, senão também não funciona.

     

    Outra coisa: Me soa "estranho" quando você diz que vai reinventar as sessões via banco de dados. Se está especificado que não pode ter servidor de estado, então pior ainda é fazer a mesma coisa que o servidor de estado faz, ainda mais na mão, o que vai abrir um monte de preodupações ainda maiores do que usar algo built-in. Eu sugiro repensar nisso, porque para mim não fez sentido.

    domingo, 25 de fevereiro de 2007 21:37

Todas as Respostas

  • Antonio,

    além da opção padrão de armazenar os dados de sessão no processo do ASP.NET, há também a possibilidade de que a sessão do usuário fique armazenada em servidores de estado ou em banco de dados SQL Server. Isso é ideal para ambientes do tipo Web Farm, no qual há balanceamento de carga entre os servidores. Você disse que não vai usar essa funcionalidade. Entendi certo? Como você vai cuidar disso?

     


    Ricardo Oneda
    http://oneda.mvps.org/blog

    quinta-feira, 22 de fevereiro de 2007 19:07
  • Antonio,

    Nao existe problemas referentes a isso: apesar de outras solucoes comentadas acima sao mais tradicionais. Esse modelos (Out-Of-Proc - ) apesar disso tem suas observacoes, como o rendimento, a validacao do mesma machine key entre os servidores e a serializacao dos objetos que devem ser avaliadas.

    Abs

    FC
    http://sushinetcode.blogdrive.com

    quinta-feira, 22 de fevereiro de 2007 21:26
  • Eu concordo com vocês quando vocês afirmam que State Server Out of Proc é melhor. No entanto estamos atendendo Gestão Pública e temos que nos submeter aos padrões de Infra Estrutura deles (que foi determinado no Edital da Licitação), pelo menos inicialmente, então a idéia é usar Forms Authentication pra manter a Sessão do usuário e o que nós manteriamos em Session vamos manter em algo parecido com State Server no SQL, mas controlado pelo sistema.


    Muito obrigado pelas opiniões!

    Att.,
    Antonio Carlos
    sexta-feira, 23 de fevereiro de 2007 11:54
  • Se você não vai usar um state server, o melhor mesmo é configurar seu NLB para afinidade de sessão. Assim, uma vez o cara se autenticando num servidor, ele só acessa esse mesmo servidor dali em diante. Fica mais fácil e você não tem que se preocupar com nada, nem mesmo que autenticação usa.

     

    Agora, se você não vai ter afinidade de sessão, então ambos os servidores precisam responder no mesmo domínio, o que provavelmente vai acontecer mesmo, já que você vai usar NLB. Também eles precisam ter os machine keys sincronizados, senão o forms authentication de um não vai ser reconhecido pelo outro. E se eles tiverem subdomínios (tipo site.com, algumacoisa.site.com, outracoisa.algumacoisa.site.com) então o endereço do cookie de autenticação tem que apontar pro domínio raíz, senão também não funciona.

     

    Outra coisa: Me soa "estranho" quando você diz que vai reinventar as sessões via banco de dados. Se está especificado que não pode ter servidor de estado, então pior ainda é fazer a mesma coisa que o servidor de estado faz, ainda mais na mão, o que vai abrir um monte de preodupações ainda maiores do que usar algo built-in. Eu sugiro repensar nisso, porque para mim não fez sentido.

    domingo, 25 de fevereiro de 2007 21:37
  • Então Mateus... é bastante complicado o porque disso.

    Na última consultoria que trabalhei atendiamos quase que a totalidade de sistemas da Globo e por algum motivo eles não conseguiam deixar o State Server em pé de forma alguma e até cogitaram em comprar ferramenta de terceiros para isso. Portanto não tinhamos a possibilidade de usar State Server e de forma alguma eles deixavam nosso arquiteto de Infra trabalhar em cima disso. Hoje, já em outra empresa estamos atendendo gestão pública e da mesma forma que expliquei acima não temos acesso a arquitetura fisíca e configuração dos servidores dos caras e temos que simplesmente acatar a decisão de não ter o State Server nativo. Isso tudo é complicado de quebrar porque foi definido em Edital para Licitação então é algo bem complicado. No entanto infelizmente de vez em quando é necessário ter algo parecido com um State Server dentro da aplicação e desde então, na época da Globo desenvolvemos um esquema muito bacana que apelidamos de DBSession e já temos toda uma maturidade em cima do uso dele. Performance comprovada por stress test, load test, etc. e mais o know how de utilização do mesmo.

    Concordo contigo que é bastante estranho usar esse tipo de artimanha, mas dentro do cenário que podemos chamar de "político" foi a única forma de contornar.

    Obrigado pelas dicas!

    Att.,
    Antonio Carlos

    segunda-feira, 26 de fevereiro de 2007 13:11