The Tiers of a Clone - Part Two (Warning, this is controversial)
As a point of note I am writing this on a Virgin High Speed Train going from Preston, Lancashire to London Euston, this is the way to travel in my opinion, much more comfortable than flying, much less hassle and unlike driving, no traffic!
Quite some time ago I wrote a piece detailing the traditional approach to building out N-Tier application architectures, that article can be found here. From the client-server world forward, it is typically accepted that for applications to be fault-tolerant and scalable, that they should have multiple tiers of infrastructure. I believe the ongoing emergence and proliferation of 64 bit architectures might change that. Why, you may ask, is that?
Before I get into that, let us go back in time back to pre client-server, what did enterprise applications typically run on? Main-frames, which of course are still widely used where ultimate reliability is required. It was not typical to have a server farm of main frames and this lack of multiple servers to maintain made for much simpler maintenance routines and in some ways helped to ensure a easier route to stability. I am not suggesting we will go back to dumb terminals where everything was done on the server, the point I am trying to make is that the new breed of 64 bit servers are bringing a lot of memory space we can use, the difference between 32 and 64 bit in terms of memory space is tremendous. There is a Microsoft Knowledge Base article here which shows comparisons between 32 bit and 64 bit, I will just highlight one entry - Virtual Memory 4GB (32bit), 16TB (64 bit).
On 32 bit servers we could not use much in excess of 4GB of contiguous memory (on Windows 2-3GB). If we look at the CF-J2EE world this pretty much meant that using multiple instances had a 3-4 instance ceiling per physical server. Because instances with less than 768MB per instance could easily run out of memory if they were supporting a busy application. You can find references to this all over the Internet. According articles I have read, such as this one, once an application has to cross from one process to another there is a degradation in performance of around 1,000 fold; that is a startling number. As we cross further boundaries such as hard disk i/o, network layers etc things are even more degraded.
In my opinion the perfect HA (High Availability) and scalable tiered infrastructure would comprise of the following minimum specifications:
- Two multiprocessor 64 bit servers with as much RAM as possible (minimum 64GB). In my opinion we move to a totally different paradigm of reliability (HA) as soon as we go from 1 to 2 of anything. Adding more gains us hardly anything in terms of improved HA.
- Hard drive configuration should be three Raid 10 Arrays and a single Raid 5/6 array. The Raid 10 arrays would service the operating system on one array, other binaries-programs on the second and all logging on the third. The Raid 5/6 array would be used for storage and I would avoid a NAS (network attached storage) or SAN (storage area network), as both of those solutions cross boundaries. This means the Raid 5-6 array needs to be as large as possible to contain all data, media files etc and needs to be replicated between the two physical servers. The arrays should have dedicated controllers for maximum throughput.
- The network interfaces (NIC's) should run at a minimum of 1GB Ethernet and there should be a minimum of two in use at all times. One would service all incoming-outgoing traffic the other would serve as the replication interface between the two physical servers. Any more segregation of traffic via more NIC's would also help but might be difficult to architect. The NIC is a restriction point and should be seen as such. It is also important that all network devices connected to the physical server do run at a full 1GB and do not in themselves become a restriction point. Attention should be paid to the physical coupling of the NIC's to the server/motherboard to ensure maximum throughput.
- Architect applications so that they can run totally in a dedicated process. In the CF world the macro view is of single instances sub divided by cfapplication tags into separate applications. In the java world there is the application context which is something I want to explore and blog further about. The amount of memory space available to us in 64 bit ainfrastructures affords us much more memory space per instance. Thoroughly planning architecture and engineering that efficiently work together is critical, once again the goal being to limit the crossing of boundaries by related-dependent processes. I feel that encapsulation for security purposes can be engineered at the instance level.
In this theoretical proposal we would keep discrete and related application operations within single process spaces and all server operations would run on each physical server, including major application pieces such as the RDBMs. A point of note here, is that in the mainframe world the database and everything else ran on that single physical system.
As I say in the title of this blog post, this is a controversial viewpoint which in many ways goes against the N-Tier methodology largely in use today. However, multiple boundaries cause degradation in performance and multiple physical entities increase the complexities of maintenance.
As always, I welcome any thoughts or comments on the blog piece.