Azure 开发 - 如何停止 Web 角色实例
我需要测试我的代码如何处理开发环境中 Web 角色实例的失败。
如何终止其中一个实例？我在用户界面中看不到任何与此相关的选项。似乎是一个奇怪的遗漏
更新
问题与分布式缓存层有关（我知道azure提供了自己的缓存层） 我希望能够测试系统对丢失或附加节点等的反应，
我真正的问题是
RoleEnvironment.CurrentRoleInstance.Role.Instances 是如何最新的
I need to test how my code will handle the failure of a web role instance in a development environment.
How do I terminate one of the instances? I can't see any option in the UI for this. Seems like a strange ommission
Update
The issue is relating to a distributed cache layer (I know that azure offers their own)
I want to be able to test how the system reacts to a missing or additional node etc
Prehaps my real question is
how up to date is RoleEnvironment.CurrentRoleInstance.Role.Instances
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
通常需要在开发模拟器中模拟不正常退出，因为您正在 Web 角色中执行有状态或长时间运行的操作。这通常是不鼓励的，但有时是不可避免的。
我怀疑模拟故障的最佳方法是终止进程。如果您打开任务管理器（或更好的 Process Explorer），您将看到托管“WaIISHost”或“WaWorkerHost”的“WatDebugger”。如果你杀死这个进程，我认为它会模拟失败。
老实说，在云中测试这个更容易。您可以通过 RDP 进入其中一个实例并终止“WaAppAgent”进程。这将杀死您的 RoleEntryPoint 和结构控制器代理。那将是真正的不体面的失败。
The need to simulate ungraceful exits in the dev emulator usually is done because you are doing something in your web role that is stateful or long running. That is generally discouraged, but sometimes is unavoidable.
I suspect the best way to simulate the a failure is to kill processes. If you open task manager (or better Process Explorer), you will see "WatDebugger" hosting either "WaIISHost" or "WaWorkerHost". If you kill this process, I think it will simulate a failure.
Honestly, it is easier to test this one in the cloud however. You can RDP into one of the instances and kill the 'WaAppAgent' process. That will kill your RoleEntryPoint and fabric controller agent. That will be a true ungraceful failure.
你所说的失败是指变得无能吗？它应该是无缝的，因为下一个请求将简单地由其他实例之一处理。只要有一个可用实例，Azure 就会将调用路由到该实例。
这是高可用系统的本质，请求由可用实例处理。这就是为什么您首先需要多个实例，以便在一个或多个实例发生故障时处理请求。
这就是为什么您需要始终注意应用程序如何处理状态。状态需要在实例外部维护，无论是在队列中还是在数据库中。这确保任何进程都可以获取一项工作并对其执行。
还有另一个处理会话状态的问题应该有所帮助： Microsoft Azure 如何处理会话状态？
By failure, do you mean becoming unavailable? It should be seamless because the next request would simply be handled by one of the other instances. As long as there is one instance available Azure will route calls to that instance.
This is the nature of a high-available system, requests are handled by the available instances. This is why you have multiple instances in the first place, to handle requests in the case of failure in one or more instances.
This is why you need to always be watchful of how your application handles state. State needs to be maintained outside of the instance, either in queues or in a database. This ensures that any process can pickup a piece of work and execute against it.
There is another question dealing with Session State that should help: How does Microsoft Azure handle Session State?
终止一个实例是指减少实例数量并查看哪个实例被杀死吗？我喜欢瑞安关于不优雅退出的观点，但如果是被结构强行杀死，那将是一场不同的比赛。
By terminate an instance do you mean reducing instance count and see which one gets killed? I like Ryan's view about ungraceful exits, but if it's forced kill by the fabric it'll be a different ball game.