Windows Azure,解决实例和粘性会话

发布于 2024-12-17 20:59:17 字数 234 浏览 1 评论 0原文

为了概念证明文件,我收集了有关 Windows Azure 的事实。还有 2 个主题我找不到明确的答案。

  1. 粘性会话/粘性负载平衡是不可能的,对吗?也许在 Azure 流量管理器 (WATM) 的帮助下有可能?

  2. 可以解决部署的单个实例吗?或者它们都在 Azure 的不透明墙后面吗?或者至少,一个实例可以在运行时确定它自己的 id 或类似的东西,以便将其写入日志吗

For a proof of concept paper, I collected facts about Windows Azure. There are 2 topics remaining I could not find a definitive answer for.

  1. Sticky sessions/sticky load balancing is not possible, am I right? Maybe there is a possibility with the help of Azure traffic Manager (WATM)?

  2. Can single instances of a deployment be addressed, or are they all behind this non-transparent wall of Azure? Or at least, can an instance at runtime determine its own id or something like that in order to write it into a log?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

嗫嚅 2024-12-24 20:59:18

请在下面找到答案:

  1. 粘性会话/粘性负载平衡是不可能的,对吗?也许在 Azure 流量管理器的帮助下有可能
    (WATM)?

你是对的。与 Windows Azure 之间没有粘性会话。不,您不能使用流量管理器来帮助您提高粘性。流量管理器只会帮助您在角色之间分配负载,而不会帮助您在实例之间分配负载。请区分角色和实例。请查看此问题,了解有关角色和实例的更多信息。

2。可以解决部署的单个实例吗?还是它们都位于 Azure 的不透明墙后面?或者至少可以
实例在运行时确定它自己的 id 或类似的东西
命令将其写入日志?

您无法寻址特定实例。所有这些都位于 Windows Azure 负载均衡器和防火墙后面。但您可以从代码中发现您当前的角色实例。使用 CurrentRoleInstance 属性 < a href="http://msdn.microsoft.com/en-us/library/ee773173.aspx" rel="nofollow noreferrer">RoleEnvironment 类。这将是 RoleInstance 类型的对象,其中有一个 ID 属性。

Please find the answers bellow:

  1. Sticky sessions/sticky load balancing is not possible, am I right? Maybe there is a possibility with the help of Azure traffic Manager
    (WATM)?

You are correct. There no sticky sessions with Windows Azure. And no, you cannot use Traffic Manager to help you about stickiness. Traffic Manager will only help you distribute load across Roles, not instances. Please do make a difference between Role and Instance. Take a look at this question for more info on Roles and Instances.

2. Can single instances of a deployment be addressed, or are they all behind this non-transparent wall of Azure? Or at least, can an
instance at runtime determine its own id or something like that in
order to write it into a log?

You cannot address a specific instance. All are behind Windows Azure Load Balancers and FireWall. But you can discover, from the code, which is your current role instance. Use the CurrentRoleInstance property of RoleEnvironment class. This will be an object of type RoleInstance, which has an ID property.

清醇 2024-12-24 20:59:18

正如 astaykov 所指出的,角色实例始终位于防火墙后面,您无法从部署外部访问特定实例。

实现粘性会话的唯一方法是构建请求路由器。一旦您运行了该角色(例如,在其自己的 Web 或辅助角色中,如 Sharptooth 所指的示例中,在同一部署中),该角色就可以访问部署中其他角色的内部端点。

虽然内部端点没有负载平衡,但请求路由器可以枚举内部端点的所有实例(获取每个实例的 ip:port),然后执行自己的负载平衡或路由。

有关使用内部终结点的角色间通信的示例,请查看这篇 msdn 文章

As pointed out by astaykov, role instances are always behind a firewall, and you have no ability to access a specific instance from outside your deployment.

The only way to accomplish sticky sessions is to build a request router. Once you have this running (e.g. in its own Web or Worker role, as in the example pointed to by sharptooth, within the same deployment), that role can then access internal endpoints of the other roles in the deployment.

While internal endpoints aren't load-balanced, the request router may enumerate all instances of an internal endpoint (getting ip:port for each) and then do its own load balancing or routing.

For an example of inter-role communication using internal endpoints, take a look at this msdn article.

初见你 2024-12-24 20:59:18

目前还没有明确的答案,但三个最佳选择是:

  1. 状态服务器 - 这将允许您从服务器到服务器甚至在网络外部获取加密数据。您可以通过在 Web 应用程序或服务器的每个实例上实现状态服务器来实现此目的。

  2. SQL Server(在内存中,仅在 2014 年及更高版本中可用)

  3. Azure 上的 Redis 缓存

这三个选项几乎解决了我在过去三年中遇到的所有会话问题。

There isn't a definitive answer yet, but the three best options are:

  1. State Server - This will allow you to get encrypted data from server to server even outside your network. You can do this by implementing a State Server on each instance of your web applications or servers.

  2. SQL Server (in memory, this only is available in 2014 and newer versions)

  3. Redis Cache on Azure

The three options have handled just about any session issue I've come across in the last three years.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文