1

Here's the scenario.

We have a Windows Server 2012 R2 Hyper-V Edition hosting three NLB 2012 R2 web servers with our product on them. They receive XML data from connected public servers and work fine.

We have a web service that checks for xDoS attacks (this looks like an endpoint blasting out logical duplicate XML messages to the cluster) or buggy endpoints that send then in "out of control loops. The receivers on each of the IIS servers call the web service to see if they should process or deny a message a given message. Needless to say this must be very fast and since this is a cluster there either has to be:

  • a common place where data is stored about past received messages
  • a common web service where this data is held in memory

The logical place for the first option would be a database, but that option would slow down the process too much. We are getting thousands of messages per second and can't add that overhead to each.

A common web service works pretty well, but when a server in the cluster goes down, the choreography between the remaining servers is pretty complex - they need to decide who gets to be the master, and when the server than went down comes back up, it needs to rejoin the others, etc...

Here's the issue...

Since all the VMs are stored on a common Hyper-V host, could we just add IIS to the host and run the xDoS checker web service there? That web service is always only going to be called from the IIS servers hosted on it (no public access). This would mean no choreography because the only time it would go down is when all of the others were going down anyway.

Here's the question...

Bad practice? If so, why? For me, "because someone else doesn't do it that way" or some variant of that is not a good reason for why, by the way.

Many thanks, Rob

rchutch
  • 11
  • 2
  • 2
    `Bad practice? If so, why?` - Probably because the Hyper-V host shouldn't be concerned with or enlisted for any other purpose or role. I know you don't want a pat `because nobody does that` answer but the fact is, nobody does that. Why don't you just build a dedicated xDOS checker VM? – joeqwerty Mar 19 '15 at 15:19
  • I like your idea. I'm not sure I can convince customers that the xDoS service itself justifies having its own server, but your idea makes sense. That would depend on how they license Windows Server. But, the idea made me think about some other services could be reasonably shared on such a machine. Many thanks. – rchutch Mar 19 '15 at 15:37
  • 1
    If the customer wants the xDOS service, and it's important to the proper operation of the system, and it's absence would have a negative impact on the availability and stability of the service and that in turn has a negative financial or operational impact to their business then they won't balk at having to pay for it... if they're smart. Also, don't give them the choice. Make it part and parcel of the solution. – joeqwerty Mar 19 '15 at 15:41
  • everything deserves it's own server in a virtual environment. There are very few reasons to combine roles on any of the modern hypervisor platforms. However you could eliminate all of this by using the azure pack services and route your messages to IIS worker roles thru a service bus instead of having them generically listen (maybe for v2) – Jim B Mar 19 '15 at 16:15
  • Also, you can't add IIS to a hyper-v edition host: https://mountainss.wordpress.com/2013/05/02/microsoft-window-server-2012-products-and-editions-comparison-winserv-hyperv/ – Todd Wilcox Mar 19 '15 at 21:27

0 Answers0