Here\u2019s a simplification of what the design of our on-premises implementation looked like:<\/span><\/p>\n Our going-in assumption was that we would use a pair of ELBs. \u00a0It was remarkably quick to configure. \u00a0In under an hour, we had built out an ELB to front the web servers, and an ELB to front the application servers. \u00a0It was so easy to set up. \u00a0Too easy, as it turned out.<\/span><\/p>\n During functional testing, we observed very strange session collisions. \u00a0We worked with our partners, looked at configuration settings, and did quite a bit of good, old-fashioned shovel work. \u00a0The big sticking point turned out to be in how we have OnBase authentication implemented. \u00a0Currently, we are using Windows Challenge\/Response (<\/span>NTLM<\/span><\/a> to be specific, dating back to the days of NT LAN Manager) to authenticate users. \u00a0The problem is, NTLM authentication does not work across an HTTP proxy because it needs a point-to-point connection between the user\u2019s browser and server. \u00a0See <\/span>https:\/\/commscentral.net\/tech\/?post=52<\/span><\/a> for an explanation of NTLM via an ELB.<\/span><\/p>\n When an IIS server gets a request, it sends a 401 response code (auth required) and keeps the HTTP connection alive. \u00a0An HTTP proxy closes the connection after getting a 401. \u00a0So in order to proxy traffic successfully, the proxy needs to be configured to proxy TCP, not HTTP. \u00a0NTLM authenticates the TCP connection.<\/span><\/p>\n In order to get past this obstacle, we ended up standing up an EC2 instance with HAProxy on it, and configuring it to balance TCP and stick sessions to backends. \u00a0Properly configured, we were cooking with gas. \u00a0<\/span><\/p>\n For our production account, we make extensive use of reserved instances. \u00a0On a monthly basis, 85% of our average workload is covered by a reservation. \u00a0For OnBase, we use t2.large running Windows for our application servers.<\/span><\/p>\n Currently, a one-year reservation costs $782. \u00a0If you were to run the same instance at the on demand rate of $0.134 per hour, the cost for a year would be $1174. \u00a0For an instance which needs to be on 24×7, reservations are great. \u00a0For a t2.large, we end up saving just over 33%.<\/span><\/p>\n Due to application load characteristics and the desire to span availability zones, we ended up with four application servers. \u00a0However, from a workload perspective, we only need all four during business hours: 7 am to 7 pm. \u00a0So, 52 weeks per year, 5 days per week, 12 hours per day, $0.134 per hour. \u00a0That comes out to just over $418, which is a savings of over 64%. \u00a0If you can schedule, by all means, do it!<\/span><\/p>\n So, where did we end up? \u00a0Consider the following simplified diagram:<\/span><\/p>\n The web servers are in separate availability zones, as are the application servers. \u00a0There are still single points of failure in the design, but we our confident in our ability to recover within a timeframe acceptable to our customers.<\/span><\/p>\n We learned quite a bit here, including:<\/span><\/p>\n Coming soon, migrating the OnBase database.<\/p>\n","protected":false},"excerpt":{"rendered":" Good to have Goals One architectural goal we had in mind as we designed our OnBase implementation in AWS was to break out the single, collapsed web and application tier into distinct web and application tiers. Here\u2019s a simplification of … Continue reading ![\"SBN](\"http:\/\/sites.nd.edu\/devops\/files\/2016\/06\/SBN-Existing-2.jpeg\")
<\/a>
\nDue to licensing considerations, we wanted to retain two, right-sized web servers behind an Elastic Load Balancer (ELB). \u00a0We then wanted to have that web tier interact with a load balanced application tier. \u00a0Since licensing at the application tier is very favorable, we knew we could horizontally scale as necessary to meet our production workload.<\/span><\/p>\nTo ELB, or not to ELB, that is the question<\/b><\/h1>\n
Enter HAProxy<\/b><\/h1>\n
A word on scheduling<\/b><\/h1>\n
Simplified final design<\/b><\/h1>\n
<\/a><\/p>\nSo, what did we learn?<\/b><\/h1>\n
\n