asp.net 负载均衡_负载平衡和ASP.NET

asp.net 负载均衡

Deployed a site this weekend with much success.  A few things that one always needs to remember when putting out a "site" that's on more than one server ("box").

这个周末成功部署了一个站点。 放置多台服务器(“盒子”)上的“站点”时，通常需要记住一些事项。

• In-process Session State + More than One Web Server: If you're using in-proc Session on ASP.NET, remember that the session has "affinity" with the server.  That means that if www2.hanselman.com is the first server the user ever hits, the user will get an ASPSESSIONID cookie that is an index into the Cache object (the In-Proc Session is really just a key to a Hashtable-type structure inside the Cache/Application) that only exists in the memory of THAT ONE SERVER.  So, since you're using Load Balancing (you have more than one server) it's important to ensure you're using "sticky connections" or node-affinity to guarantee the user gets back to his/her session on the next HTTP Request. 

  进程内会话状态+多个Web服务器：如果在ASP.NET上使用进程内会话，请记住该会话与服务器具有“亲缘关系”。 这意味着如果www2.hanselman.com是用户访问过的第一台服务器，则用户将获得一个ASPSESSIONID cookie，该cookie是Cache对象的索引(过程中会话实际上只是Hashtable类型结构的关键缓存/应用程序内部)(仅存在于该服务器的内存中)。 因此，由于您正在使用负载平衡(您有多个服务器)，因此确保您使用“粘性连接”或节点亲和性以确保用户在下一个HTTP请求上返回其会话非常重要。

  Note that it's often tricky to get a user back to the same box when dealing with "mega-proxies" of large corporations, ISPs, and AOL.  That means that if your load-balancer (hardware or otherwise) is looking at various combinations of IP+VPORT+Whatever that these values MAY CHANGE if the ISP changes their source port or IP address.  If you're using SSL, you can use the SSL ID to route traffic, but this can slow you down a smidge.  You can also let the hardware loadbalancer add in a cookie of its own.  Check your loadbalancer's FAQ for details.  But, it's worth being aware of the things

  请注意，在处理大型公司，ISP和AOL的“大型代理”时，使用户回到同一位置通常很棘手。 这意味着，如果您的负载均衡器(硬件或其他)正在查看IP + VPORT +的各种组合，那么，如果ISP更改其源端口或IP地址，则这些值可能会发生变化。 如果您使用的是SSL，则可以使用SSL ID路由流量，但这会降低速度。 您还可以让硬件负载平衡器添加自己的cookie。 有关详细信息，请查看您的负载均衡器的FAQ。 但是，值得注意的是

• Out-of-Proc (State Server) + More than One Web Server: If you are using the State Service, you might think about putting it behind your second firewall, in a different DMZ than both the Web Servers or the Database. 

  进程外(状态服务器)+多个Web服务器：如果您正在使用状态服务，则可能会考虑将其放置在第二个防火墙之后，位于与Web服务器或数据库不同的DMZ中。

• Out-of-Proc State Server + ONLY ONE Web Server:  Some folks use the Session State Service even if they have only one Web Server so the session state isn't lost when the ASPNET_WP.EXE process recycles.  If you do this, make sure to lock down the state service to serve local requests only.

  进程外状态服务器+唯一一台Web服务器：有些人即使没有一台Web服务器也使用会话状态服务，因此当ASPNET_WP.EXE进程回收时，会话状态不会丢失。 如果这样做，请确保锁定状态服务以仅服务本地请求。

  Out-of-Proc State Server + ONLY ONE Web Server:  Some folks use the Session State Service even if they have only one Web Server so the session state isn't lost when the ASPNET_WP.EXE process recycles.  If you do this, make sure to lock down the state service to serve local requests only.

  进程外状态服务器+唯一一台Web服务器：有些人即使没有一台Web服务器也使用会话状态服务，因此当ASPNET_WP.EXE进程回收时，会话状态不会丢失。 如果这样做，请确保锁定状态服务以仅服务本地请求。

  HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnections

  HKLM \ SYSTEM \ CurrentControlSet \ Services \ aspnet_state \ Parameters \ AllowRemoteConnections

  You can also change the port that the state service listens on with the following key:

  您还可以使用以下键更改状态服务侦听的端口：

  HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\Port

  HKLM \ SYSTEM \ CurrentControlSet \ Services \ aspnet_state \ Parameters \ Port

  If you're using the state server in a web farm, it's important that you put it behind a firewall or otherwise prevent anything but the web servers from talking to it. [Early and AdopterEarly and Adopter]

  如果要在Web场中使用状态服务器，则将状态服务器放置在防火墙后面或以其他方式阻止除Web服务器之外的任何设备与之通信非常重要。 [早期和采用者早期和采用者]

• WebFarm Gotchas: When you're using either the State Service or SQL Server Session State, you're indicating that you don't want "session affinity" and you'll probably set your Load Balancer to Round-Robin dispatching of traffic. (It won't using any smarts or algorithms to get traffic, it will just go 1, 2, 3, etc.)  When you do this AND you're using Forms Authentication OR you have EnableViewStateMAC set to protect your ViewState, remember to synchronize your <machinekey> between all machines in the farm.  As users move around your site, each page could put served up from a different machine, meaning that not only are your encrypted forms-auth cookies passed around, but your ViewState (protected by the machinekey) may be sourced from one machine, and posted to another.

  WebFarm陷阱：使用状态服务或SQL Server会话状态时，表示您不希望“会话关联”，并且可能会将负载均衡器设置为流量的循环调度。 (它不会使用任何智能或算法来获取流量，只会流向1、2、3等。)在执行此操作且您使用的是表单身份验证时，或者您已设置EnableViewStateMAC来保护ViewState时，请记住在服务器场中的所有计算机之间同步您的< machinekey >。 当用户在您的网站上四处移动时，每个页面都可能从不同的计算机上投放，这意味着不仅传递了加密的表单-身份验证Cookie，而且您的ViewState(受计算机密钥保护)也可能来自一台计算机并发布到另一个。

• Security: Remember to secure the crap out of everything you do. 

  安全性：请记住，不要做任何事情。

翻译自: https://www.hanselman.com/blog/load-balancing-and-aspnet

asp.net 负载均衡